Computerized securities trading platform system, method, and architecture

Abstract

To provide a system and a method for processing a transaction order.SOLUTION: A system and a method for processing a transaction order includes a strategy matching venue, where the strategy matching venue is configured to process a strategy order having each strategy specifying a reference rate or a range of reference rates. The strategy order is matched to a contra-strategy order that is compatible but may have different strategies. A single match produces a stream of implementations at the maximum rate compatible with the strategy of the matched order. An additional system operates to generate a strategy order from a conventional algorithm order and adjust the algorithm order for selection to satisfy the strategy order by the strategy matching venue.SELECTED DRAWING: Figure 12B

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application claims priority to U.S. Provisional Patent Application No. 62 / 799,170, filed January 31, 2019, the entire contents of which are expressly incorporated by reference.

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

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

[0004] Thus, a large order is broken down into many smaller, discrete sub-orders according to an algorithmic ("algo") process. These sub-orders are easier to fill, or at least individually have less impact on the market price of the security. This can reduce the overall price impact of filling a large order. The trade-off in this execution decision is the acceptance of market and execution risk due to the longer execution period that results from trading in smaller orders that are filled at a slower rate.

[0005] In traditional trading systems, this type of large order is processed using a computerized trading platform. The computerized trading platform employs an algorithmic trading system that automatically slices the large order into many discrete smaller orders according to an explicitly selected algorithmic execution strategy. The smaller orders are routed to trading venues, where they are individually matched and processed with contraorders at each trading venue. In terms of execution rate, filling a single large order requires an execution rate greater than the current market liquidity rate. The applied algorithmic strategy attempts to fill the large order with an execution rate (the percentage of filled share of market volume) equal to the available liquidity in the market (the percentage of available volume to total market volume). There are various different types of algorithmic trading strategies in use. 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 placed by an institutional trader via an order management system (OMS) or execution management system (EMS). The order is delivered to a broker dealer implementing an algorithmic trading system. The algo order management periodically slices the child order in an amount and frequency that depends on the algorithmic strategy being used and new and / or historical market data. In a percentage of volume (POV) strategy, the order is sliced ​​at a specified percentage of market volume. Thus, a 10% POV process might specify that a 2,000 share child order be sliced ​​every time market data indicates that another 20,000 shares of XYZ have traded.

[0007] The child orders are sent to the algo trading platform's Smart Order Router (SOR), which further divides each child order into even smaller, discrete grandchild buy orders, typically of only a few hundred shares, which are then sent individually by the SOR to multiple trading venues. Each trading venue then attempts to match these smaller grandchild orders with a dormant contra-order for execution. A conditional order may be sent to multiple trading venues and then canceled after one venue is able to fulfill it.

[0008] Algorithmic trading processes are a major component of the high-frequency trading-centric market structure currently in place, contributing to the fragmentation and decline in average trade sizes that characterize traditional equity markets. Using this traditional methodology, fulfilling a single large order requires the generation and processing of thousands of discrete, smaller orders. Assuming the current average trade size is 200 shares across the entire U.S. equity market, an institutional algorithm would need 500 trades to complete an order of 100,000 shares. To achieve 500 executions, a typical algorithmic strategy would issue 5,000 orders, the majority of which are ultimately canceled. This geometric explosion of orders resulting from algorithmic slicing is further exacerbated by high-frequency trading market makers in a market structure that rewards the fastest orders, increasing processing overhead. It also increases the risk of disrupting entire financial data networks, as reflected in the increasing occurrence of flash crashes.

[0009] Because bilateral orders are split into many discrete smaller orders for processing before buy / sell matching occurs, traditional algo trading systems and execution venues are unable to identify situations in which a large order can be fully or partially matched with a contra-order. 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 institutional investor B wants to buy a large number of shares of the same security at the same venue, time, and strategy, existing trading systems are unable to match the parent orders. Thus, institutional investors are limited to either large trades at one price (typically treated by brokers as special orders with high commissions) or small, slow trades across a range of times, volumes, prices, venues, and counterparties.

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

[0011] Traditional algo trading systems and methods are inherently flawed in terms of time-matching or optimizing a benchmark. As a result, algo order systems are designed to achieve a certain benchmark and minimize shortfalls, but cannot perfectly match the benchmark. The liquidity available at different venues (orders of different quantities and dormant limits) is continuously changing, and the SOR used by the algorithmic processor for grandchild orders continuously reacts to market data from all these venues, which can be delayed. As a result, algorithmic platforms are constantly trying to pursue liquidity. On average, algo platforms will always underperform a benchmark that reflects the best achievable price based on the best liquidity available at all venues.

[0012] Furthermore, trading venues cannot accurately match orders at the algorithmic strategy level. Even cross-venue trajectories rely on ex-ante volume estimates of securities to size the "trajected" volume, which creates slippage through volume forecasting errors. Furthermore, despite typically over-representing liquidity needs across multiple venues (e.g., by placing excess conditional orders), algorithms cannot miss trading volume everywhere. Therefore, due to speed and latency disadvantages, the queue position of broker implementation algorithms at trading venues is typically lower in priority than high-frequency market makers that specialize in cross-venue latency arbitrage. As a result of these and other inefficiencies, aggregate benchmark slippage can exceed $100 billion annually in the U.S. equity market. Summary of the Invention [Problem to be solved by the invention]

[0013] These inefficiencies, limitations, and other shortcomings are addressed by a trading system architecture and method in which orders are placed with a selected strategy having a rate or range and are matched at an implicit rate to a targeted execution strategy for a contra-order in a strategy matching venue. Unlike traditional venues in which 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 an unlimited stream of quantities, prices, and trades, each according to a compatible rate for the matched order's strategy. Prices and quantities can be based on prices and sizes occurring in a continuous market, and the stream of matching executions can continue until either the parties' order quantity or price range limits are exhausted, violated, or canceled.

[0014] For example, a buyer and seller with a trading strategy having a 10% execution rate can be matched with a strategy matching venue and a stream of executions generated that exactly matches the desired ratio, even though neither party knows the other side or the strategy.

[0015] A strategy order can specify a security, side, quantity, limit price, and a specific 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 contraorders with 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 and used by different users.

[0016] Strategies can be given different matching priorities, such as priorities based on liquidity rates implicit in execution strategies. Organizing trading priorities around rates instead of prices advantageously allows rate-based execution strategies to better match venue liquidity. Market participants compete for liquidity based on the rates requested and offered, instead of competing on price and speed of order submission, as in traditional systems.

[0017] The system, method, and architecture can be implemented in three main parts that can interact with each other but can also 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-routine 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. Non-strategy orders submitted to the strategy matching venue may be assigned a default strategy. A marketability function may be periodically applied to the stored strategy orders to identify marketable orders. Marketable orders that have available rate capacity to exchange tradable units, such as securities, are considered tradable.

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

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

[0021] The HERO system can operate in close conjunction with existing algorithmic (algo) trading systems, such as those used by brokers / dealers. The HERO system integrates with algorithmic trading systems and generates strategy orders by converting algorithmic orders placed in the algorithmic trading system into strategy orders for strategies supported by the Strategy Matching Venue. Predefined strategy mapping rules can be used to select the specific strategy type to be applied based on the attributes of the corresponding algorithmic order and based on user preferences. Different users may prefer different methods for mapping algorithmic order attributes to strategy types for strategy orders. One or more sets of strategy mapping rules can be provided for the same given set of strategies to be used for any given order, and mapping rule sets can be selected based on attributes of the order, such as the trading desk that issued it. Strategy mapping rules can define more complex rules, which may be a simple direct map from a rate specified for an algorithmic order to a strategy. Here, the strategy selected for a given algo can change dynamically based on data external to the algo order itself, such as, but not limited to, market conditions and the amount of the algo order that may already have been filled.

[0022] The HERO System interfaces with the Strategy Matching Venue and the Algo Platform to coordinate the activities of both to obtain the best trading results for algo orders. Messages are exchanged between the Algo Trading System, the HERO System, and the Strategy Matching Venue to coordinate the processing of strategy orders and corresponding algo orders, so that, when strategy order matching is available, strategy matching functions for the corresponding algo order process in the price discovery market.

[0023] The PRO system operates at a higher level in the order processing workflow than the HERO system, interfacing with the Strategy Matching Venue and the OMS / EMS and coordinating activities across both to achieve the best trading results for the trading desk. Instead of working directly with the algorithmic order platform that processes orders, as is done in the HERO system, the PRO system works with the OMS or EMS used by the trading desk to submit algorithmic orders and publish strategy orders to the Strategy Matching Venue. Strategy orders are generated in response to algo orders published by the OMS / EMS, and the strategy orders are published to the Strategy Matching Venue. Messages are exchanged between the OMS / EMS, the PRO system, and the Strategy Matching Venue to coordinate the processing of strategy orders and corresponding algo orders, and to ensure that strategy order matching favors the corresponding algo orders, if available.

[0024] The system, method, and architecture of the present invention have many advantages over conventional trading systems, particularly with regard to handling large orders. The matching process does not need to be repeated countless times when pursuing an execution strategy. Because the number of matching cycles performed is significantly reduced, the subsequent number of child orders sent per parent order is also significantly reduced. Furthermore, the need to send multiple suborders to multiple venues is eliminated. As a result, potential information leakage is limited to execution-centric participants at the strategy matching venue, and the number of third parties, such as HFT market makers, who can learn of the existence of a strategy order is significantly reduced compared to conventional trading systems. Furthermore, slippage relative to the execution benchmark is largely or completely eliminated, and absolute slippage relative to arrivals is significantly reduced due to this reduction in information leakage and the elimination of the structural shortcomings of inter- and intra-market fragmentation present in conventional systems and methods.

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

[0026] In one embodiment, an improved security trading system embodying various aspects of the present invention may comprise one or a combination of: (i) a strategy matching venue that accepts, matches, and fills strategy orders; (ii) a HERO system that interacts with a broker / dealer's algo trading platform to generate strategy orders related to algo orders functioning on the algo trading platform, submit the strategy orders to the strategy matching venue, and have the strategy orders served in preference to the corresponding algo orders; and (iii) a PRO system that interacts with an OMS / EMS that may use a conventional algo trading platform to submit orders to the broker / dealer system, where the PRO system operates to generate strategy orders related to algo orders issued by the OMS / EMS, submit the strategy orders to the strategy matching venue, and have the strategy orders served in preference to the corresponding algo orders. Conventional exchange venues may continue to service orders from the algo trading platform, for example.

[0027] In one embodiment, the strategy matching venue comprises a computerized system having appropriate hardware, memory, and network access to support desired trading levels, the system operating 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 about 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-enabled system, a PRO system-enabled 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 rate range.

[0028] A tradable first strategy order selected from the strategy orders in the strategy order book. Tradability can be determined by applying a tradability function to evaluate attributes of each strategy order and first market data. The strategy orders in the strategy order book are searched to find a first match between the first strategy order and a first contrast latitude order that has a respective strategy compatible with the strategy of the first strategy order and is tradable based on the tradability function applied to the first contrast latitude order and the first market data. The matching state of the first match is initially unbroken. The matching state breaks if either the first strategy order or the first contrast latitude order becomes untradable.

[0029] While the first match is not broken, fills for the tradable items are intermittently issued between the first strategy order and the first contrast latency order at a maximum rate compatible with the respective strategies of the first strategy order and the first contrast latency order, the fill amount being a function of the maximum rate applicable to second market data related to the tradable items. Information in the strategy order book about the first strategy order and the first contrast latency order is updated to reflect the fill amount. At least one execution message is sent to each source for the first strategy order and the first contrast latency order, each execution message indicating the executed fill amount.

[0030] In one embodiment, in response to finding the first match, a match found condition message is sent to each source for the first strategy order and the first contrast latency order.

[0031] In one embodiment, in response to each performed fill, a respective perform message is sent to the source of the first strategy order and the source of the first contrast latency order indicating the respective performed fill amount.

[0032] In one embodiment, in response to a break in the first matching, a matching termination condition message is sent to at least one of the respective sources for the first strategy order and the first contrast latency order.

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

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

[0035] In one embodiment, if multiple contraorders with compatible strategies are available to match a strategy order, the contraorders are matched according to the relative strategies. When multiple contra-orders with the same priority strategy are available, the orders can be prioritized based on one or more additional priority factors that may also include order size, orders exceeding a threshold size having higher priority than smaller orders, order source, and arrival time at the strategy matching venue.

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

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

[0038] In one embodiment, a strategy order can be conditional. If at least one of the first order and the first counter order of the first match is conditional, a conditional match can be created and information about the match is stored. A confirmation message is sent to the source of each conditional order. Fills for tradable items are not performed until each conditional order of the match is confirmed. If not confirmed within a predetermined period, the conditional match can be released.

[0039] The confirmation message can include a match ID number associated with the particular match being confirmed. The confirmation response can match the associated strategy match based on the match ID value included in the response. The confirmation response can include updates to each conditional strategy order being confirmed or a replacement non-conditional strategy order for each conditional strategy order being confirmed.

[0040] In one embodiment, the order data stored in the order book can include each order's available capacity, which 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 in terms of available volume rates or rate ranges for each order, in terms of available capacity, or by other measures. When a first strategy order and a first contrast latency order are matched, the available capacity of each order can be reduced by the expected total amount of shares to exchange between the first order and the first contra-order during the first match, by the maximum volume rate compatible with the respective strategies of the first strategy order and the first contrast latency order, or by other measures. If the available capacity of the first order remains zero or greater than a minimum threshold, the first order can be matched to additional contra-orders while the first match remains active.

[0041] In one embodiment, the strategy order may further specify an alternative strategy and a predetermined condition for activating the alternative strategy. The condition for triggering use of the alternative strategy may be specified as the difference between the current price of the associated security and the limit price of the strategy order.

[0042] In one embodiment, a strategy order change message may be received that specifies that the respective strategy quantity or limit price is to be changed. The strategy order change message may specify a strategy to be used to replace the current strategy for the respective order.

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

[0044] The algorithmic trading platform operates to process trade orders specifying tradable items, which may be securities, quantities, or sides, and which have associated algorithmic constraints by continuously generating suborders from the trade orders in accordance with the algorithmic constraints. The suborders specify respective suborder quantities and are issued to a point-in-time (PIT) trading venue. PIT fulfillment messages are received, each PIT fulfillment message corresponding to a respective suborder and indicating a fill quantity for the respective suborder, the fill quantity being less than or equal to the respective suborder quantity.

[0045] A first strategy order corresponding to the trade order is generated, the first strategy order specifying a respective strategy selected from the predetermined set of strategies according to the security and side of the trade order, a set of predetermined strategy mapping rules by the HERO system, and rules for at least one attribute of the trade order. Multiple bear predetermined strategy mapping rules can be defined, and a particular bear strategy mapping rule can be selected based on an attribute of a particular trade order, such as the trader or trader group to which the trade order was placed.

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

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

[0048] Upon receiving an execution message related to the first strategy order from the strategy matching venue, the trading volume and trading price data for each of the first strategy orders in the strategy order table are updated to specify the execution of the first order and reflect the execution volume, and the execution information from the execution message is transmitted by the HERO system to the algorithmic trading platform.

[0049] Upon receiving a matching break condition message from the strategy matching venue, the algorithmic trading platform 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, sub-order generation resumes.

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

[0051] In one embodiment, the first strategy order may specify a maximum number of shares available for strategy matching, or this may be determined later. The maximum number of shares available for strategy matching is the number of potential shares (unfilled shares of orders not routed to a trading venue) of the first strategy order minus a 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 in association with the first strategy order is determined, and a confirmation response is sent to the strategy matching venue. In one embodiment, the confirmed number of shares can be the number of potential shares associated with the first algorithmic order, or alternatively, the number of remaining shares associated with the first algorithmic trading order. In one embodiment, the confirmed response can be an update to the first strategy order specifying the confirmed number of shares, or a second strategy order associated with the first order ID or a link to the first order ID, having content specifying the confirmed number of shares; a second message canceling the first strategy order in favor of the second strategy order can also optionally be sent by the HERO system.

[0053] In one embodiment, in response to receipt by the HERO system of the firming request, the HERO system may send a cancel order instruction to the algorithmic trading platform requesting cancellation of any outstanding child orders associated with the first algorithmic order, and after receiving a cancellation confirmation message from the algorithmic trading platform, perform a firming response process in the strategy trading platform.

[0054] In one embodiment, the information about the active strategy order in the strategy order table comprises contents indicating a current number of potential shares available for the first algorithmic order, the number of potential shares being updated in response to receiving order placement information about the trade order from the algorithmic trading platform. In response to a change in the maximum number of shares available for strategy matching to 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 desired trading levels, the system operating 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 strategy orders having a specific strategy with contrasting strategy orders having a compatible strategy and initiating a stream of trade executions between the matched orders. The management system issues algorithmic orders to an algorithmic trading system.

[0056] A first trade order is received at the PRO system from a management system that identifies tradable items such as a security, a side, a limit price, and algorithm constraints. A first strategy order corresponding to the trade order is generated, the first strategy order comprising the security and side of the trade order, a pair of predetermined strategy mapping rules, and the algorithm constraints of the trade order. The method specifies each strategy to be selected from a given pair of strategies according to a rule in at least one attribute of the trade order. Multiple pair-predetermined strategy mapping rules can be defined, and a strategy mapping rule for a particular pair can be selected based on attributes of a particular trade order, such as the trading desk or broker to which the trade order was placed.

[0057] A conditional first strategy order is generated from the trade order, specifying the tradable item, side, and limit price, and further specifying the first strategy type, and has a first order ID and content. Information about 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 a minimum portion of the trading order submitted to the algorithmic trading platform will be canceled. Upon receiving the cancellation confirmation from the management system, a 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 can be an update to the first strategy order specifying the confirmed number of shares, or a second strategy order associated with the first order ID or a link to the first order ID, having content specifying the confirmed number of shares, and optionally sending a second message canceling the first strategy order in favor of the second strategy order.

[0059] A match detection condition message from the strategy matching indicates that the confirmed first strategy order has been matched with the contrast strategy order. If a match detection condition is not received within a predetermined timeout period, a reissue message is sent to the management system indicating that the canceled portion of the first trading order may be reissued.

[0060] Upon receiving an execution message from the strategy matching venue associated with the first strategy order specifying the execution of the first order for the respective trading volume and trading price, the record for 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 may include an indication of the maximum number of traded shares for the strategy order that can result from the match. In response, a message may be sent by the PRO system to the management system with this value, and the management system may reissue the algorithmic order with the number of shares available 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 the unfilled portion of the trade order may be resubmitted to the algorithmic trading platform. [Brief explanation 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 described in detail below with reference to the accompanying drawings.

[0064] [Figure 1] FIG. 1 is a high-level block diagram illustrating the system architecture for a conventional algorithmic trading platform. [Figure 2A] FIG. 2A is a high-level flowchart of conventional algo order management and the general operation of conventional algorithms. [Figure 2B] FIG. 2B is a high-level flowchart of conventional algo order management and the general operation of conventional algorithms. [Figure 3] FIG. 3 is a high-level block diagram of an improved trading system architecture in accordance with a first primary embodiment of the present invention. [Figure 4] FIG. 4 is a high-level diagram of an embodiment of the HERO system engine of FIG. [Figure 5] FIG. 5 is a high-level diagram illustrating the functional aspects of one embodiment of the HERO system and the communication between the HERO system engine and the HERO system aware algorithmic trading system. [Figure 6] FIG. 6 is an explanatory diagram of a strategy order transaction map. [Figure 7A] FIG. 7A is a high-level flowchart of the operation of the HERO system-aware algo order management. [Figure 7B] FIG. 7B is a high level flow chart of the operation of the HERO system aware algo order management. [Figure 8A] FIG. 8A is a high-level flowchart of the operation of one embodiment of the HERO system in processing an order. [Figure 8B] FIG. 8B is a high level flow chart of the operation of one embodiment of the HERO system in processing orders. [Figure 8C] FIG. 8C is a high level flow chart of the operation of one embodiment of the HERO system in processing orders. [Figure 9A] FIG. 9A illustrates an example of a HERO system-aware algorithmic trading system and the processing of a sample algo order and corresponding strategy order by the HERO system. [Figure 9B] FIG. 9B illustrates an example of a HERO system aware algorithmic trading system and the processing of a sample algo order and corresponding strategy order by the HERO system. [Figure 10A] FIG. 10A is a variation of the example of FIG. 9A. [Figure 10B] FIG. 10B is a variation of the example of FIG. 9B. [Figure 11] FIG. 11 is a high-level block diagram of the system architecture of an embodiment of a trading platform having an order management and fulfillment management system. [Figure 12A] FIG. 12A is a high-level block diagram of an improved trading system architecture in accordance with a second primary embodiment of the present invention. [Figure 12B] FIG. 12B is a high-level block diagram of an improved trading system architecture in accordance with a second primary embodiment of the present invention. [Figure 13A]FIG. 13A is a high-level flow chart illustrating aspects of operation of one embodiment of the PRO system of FIG. [Figure 13B] FIG. 13B is a high-level flow chart illustrating aspects of operation of one embodiment of the PRO system of FIG. [Figure 14A] FIG. 14A is a high-level functional block diagram of an embodiment of a strategy matching venue. [Figure 14B] FIG. 14B is a high-level functional block diagram of an embodiment of a strategy matching venue. [Figure 15] FIG. 15 is a diagram of various types of information that may be stored and used during processing of a strategy order by the strategy matching venue of FIG. [Figure 16A] FIG. 16A is a high-level flowchart of the basic functionality provided by various internal system embodiments of the strategy matching venue of FIG. [Figure 16B] FIG. 16B is a high-level flowchart of the basic functionality provided by various internal system embodiments of the strategy matching venue of FIG. [Figure 16C] FIG. 16C is a high-level flowchart of the basic functionality provided by various internal system embodiments of the strategy matching venue of FIG. [Figure 17] FIG. 17 is a high-level flow chart of one embodiment of the strategy order matching engine. [Figure 18] FIG. 18 is a high-level flow chart of an embodiment of a Strategy Trading Processor. [Figure 19] FIG. 19 is a table showing a set of order strategies. DETAILED DESCRIPTION OF THE INVENTION

[0065] FIG. 1 is a high-level block diagram illustrating the general system architecture of a conventional algorithmic trading platform (algo platform) 100 used to process orders to buy and sell securities. Algorithmic orders (algo orders) 105 originate from an institutional order management system (OMS) or execution management system (EMS) 110 and are sent to the algo platform 100. Algo orders 105 specify a side (buy or sell), quantity, and limit price. New algo orders 105 are added to an algo order table 120, which is used to track information about open algo orders. When an algo order in the algo order table 120 is selected for processing, an algo order manager 130 operates to split the algo order into many smaller, discrete child orders. The child orders 135 are successively "sliced" from the parent according to a specified execution algorithm. New algo orders 105 may also have general instructions used by algo order management 130 to control child slices to spread execution over time and / or across market volumes.

[0066] The child orders 135 are processed by a smart order router ("SOR") 140, which divides the child orders into smaller, discrete grandchild orders 145. The SOR 140 directs the grandchild orders 145 to selected PIT (point-in-time) trading venues 150. Each trading venue 150 executes point-in-time (PIT) transactions, matching received orders with contra-orders and, for each match, executing a single execution at a fixed price and a single, discrete amount of the security being exchanged at a point in time. Execution information 155 is returned from each PIT trading venue 150 to the algo trading platform 100 and is used to update internal data related to the grandchild, child, and initial orders 145, 135, 105, as appropriate.

[0067] If an order placed at PIT trading venue 150 is conditional, when the PIT trading venue finds a match for the order, it sends an invitation to the order originator, such as SOR 140, inviting them to send a definite response order. If a definite response order 160 is received, the definite response order replaces the canceled conditional order, and the definite response order is processed instead.

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

[0069] 2B, when the SOR receives a child order from the Algo Order Manager (step 216), it generates grandchild orders and then submits them to the PIT Trading Venues for fulfillment (steps 218, 210). Fulfillment information from the PIT Trading Venues is received by the SOR (step 222), and the fulfillment data is returned to the Algo Order Manager (step 224).

[0070] Returning to Figure 2A, once child order fulfillment data is received from the SOR (step 226), the Algo Order Manager updates the information for 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 for the algo order (e.g., less than N) (step 230), the Algo Order Manager continues to wait for additional fulfillment data from the SOR (step 226). If no shares remain, the entire algo order is fulfilled (step 330). Additional steps can be taken if the issued algo order, child orders, and / or grandchild orders are conditional orders to confirm the respective orders accordingly.

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

[0072] Similar to algorithmic orders, strategy orders specify an order security (or other tradable item), a side (e.g., buy or sell), and a limit price. Furthermore, in contrast to traditional trading systems, strategy orders also specify a strategy type, which is 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 traditional algo systems, such as executing at more than 100% of the volume traded in the market over a certain period of time.

[0073] A wide variety of different strategy types can be defined. Various predetermined sets of strategies can be made available for use in different situations, for trading different types of tradable items, and for use by different entities. Each institutional trader or broker dealer can have its own customized set of strategy types. Each strategy type has a rate or a range of rates and can be matched to itself, to one or more other strategy types in a predetermined set, and possibly to other predetermined sets of strategies. Strategy matching can be prioritized. In one embodiment, strategies can be prioritized according to relative liquidity rates. If one strategy can be matched by two or more other strategies, a matching strategy offering a higher rate may be given higher priority.

[0074] While a wide variety of different strategies can be defined, in one embodiment, strategies are categorized into three basic classes. The first strategy class comprises strategies that have a base rate or a range of base rates that is less than or equal to 100%. As described further below, a strategy's base rate is used in determining the execution rate of a strategy order, for example, where the execution amount is determined from a constant rate applied to a particular record of trading volume for the item in question. The second strategy class comprises strategies that have a base rate or a range of base rates that is greater than 100%. The third strategy class is liquidity search, and comprises a non-numeric rate (or infinity) that indicates that the maximum rate allowed is used during strategy order processing.

[0075] Returning to Figure 3, a 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 venues 315. The strategy matching venues 315 attempt to match received strategy orders with contrast rate orders having the same security and compatible strategies.

[0076] Once a match is found by the strategy matching venue 315, a series of fills are performed on the matched order according to compatible aspects of the matched order's respective strategy type. Instead of matching discrete and independent suborders, as is done in conventional algo trading systems 100 operating with PIT trading venues 150, the matching in the strategy matching venue 135 is open-ended and can maximize the liquidity available to the matched strategy order. A single match can result in a continuous flow of fills based on a base rate and aggregate trading volume, and strategy matching is performed so that this can occur without having to access a continuous market. The fill price can be based on the current market price of the security as reflected by market trading data and the fill volume determined as a function of current base market data, such as the order's trading strategy and the trading volume of the security as reflected by the market data. The fill flow ends when the marketable liquidity between the matched strategy orders is exhausted.

[0077] As described further below, algo orders can have associated algorithmic constraints, such as a target rate at which the algo trading platform attempts to match. Strategy orders can be generated for an algo order by selecting a strategy from a predetermined set of strategies according to predetermined strategy mapping rules. Different sets of strategy mapping rules can be defined by different system users, and the particular mapping table used can be selected depending on, for example, the party that placed the initial order. Predefined strategy mapping rules can be static and can map to a particular strategy based on the algo order target rate. Strategy mapping rules can also be dynamic, with the strategy mapped depending 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 predetermined set of strategy types and a matrix showing which strategy types match with which other types and priorities. In the illustrated embodiment, a low rate range strategy is defined as having a base rate range of 5% to 15%, and a medium strategy is defined as having a base rate range of 10% to 30%. A strategy order with a low strategy is processed in the strategy matching venue such that, when the order is matched, it is executed at a rate of 5% to 15% of the associated trading volume, with the actual rate depending on the strategy of the matched one or more contra-orders, as described further below. Similarly, a strategy order with a medium strategy is executed in the strategy matching venue at a rate between 10% and 30% of the associated trading volume. The 100% to 200% and 100% to 400% rate strategies exhibit execution rate ranges greater than 100%. An exact rate strategy specifies a single base rate, such as 7%, for execution in the strategy matching venue. Strategies may also have other ranges. The number of predefined strategies in a strategy set may vary, and increasing the number of strategies may increase the rate granularity between the various strategies. Strategies may be defined with intentional overlap to allow overlapping strategies to be cross-matched with each other.

[0079] Low and medium strategies can be matched with each other because both strategies allow rates between 10% and 15%, and therefore, transactions associated with the low strategy type can be used to fulfill at least a portion of the contra trades made by medium strategy orders (which are executed at a higher rate) without violating either order's specified strategy rate range. The rate used for execution in the strategy matching venue is the maximum rate of overlap, here 15%, although alternative embodiments may use lower rates if deemed appropriate for a particular trading situation. Similarly, the 100%-200% and 100%-400% strategy types are compatible in this respect, since an order with a 100%-400% strategy can be at least partially fulfilled by an order with a 0% strategy. The liquidity search strategy matches all interest-based and liquidity search strategies.

[0080] When a given strategy can be matched to multiple different compatible contrast strategies, priority can be given to the match with the highest potential liquidity. In Figure 19, strategy matching priority is illustratively indicated by sequence numbers 1 through 5, with 1 indicating the highest priority. As an example, a buy order with a medium (10% to 30%) strategy is preferentially matched to a contra order with a liquidity search strategy if none are available for the medium strategy and if none are available for the low (5% to 15%) strategy order.

[0081] Once a strategy order is matched to a contrast rate order, if the strategy order has additional capacity available, it can be matched to another contrast rate order, even if the other contra-order has a potentially incompatible strategy. For example, a strategy order specifying a 5-15% strategy can be matched to a contrast rate order with an accurate strategy rate of 11%. Because strategy matching is performed at the 11% rate, the initial strategy order has 15%-11% = 4% remaining capacity (while the initial strategy matching is in effect) and can therefore simultaneously be matched to a second contra-order with a strategy (or remaining strategy capacity) of <= 4%.

[0082] A set of strategy matching rules tends to map algo orders with a target trading rate X to strategies with base rates ranging from A to B, where A<=X<=B. However, this does not necessarily require the user to specify the required mapping. Furthermore, even within this condition, if two or more strategies have base rate ranges that encompass X, different users can define their own strategy matching rules that map orders to different strategies. For example, a first user can specify a rule that results in an algo order specifying an algo target rate of 12% mapping to a 5% to 15% strategy, while a second user can specify a rule that results in an algo order with the same target rate mapping to a 15% to 30% strategy. A third user can specify that any algo order with a base rate between 5% and 12.5% ​​will be mapped to the 5% to 15% strategy, while orders with a base rate greater than 12.5% ​​but less than 35% will be mapped to the 10% to 30% strategy.

[0083] Examples of strategy orders A and B with strategies selected from those in Figure 19 are shown below for a trading volume V of associated security 10000. These examples assume that the strategy orders are marketable and each has available capacity 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 exchanged. JPEG2025126224000002.jpg93146

[0084] In operation, the strategy matching venue 315 continues to execute a series of matching trades using a quantity calculated from the applied reference rate and the most recent trade volume (corresponding trade price), or the midpoint of the current bid-offer of the liquidity-seeking block seeking the match, until the order capacity of the matched pair is exhausted or one of the orders becomes unmarketable.

[0085] The HERO system 310 also communicates with an algo trading platform engine 320 configured to operate in conjunction with the HERO system (which may be referred to herein as a HERO-aware algo platform). The algo trading platform 320 and the HERO system 310 may all be implemented as part of an overall sell-side or buy-side broker-dealer system, and there are various ways to integrate the systems. When an eligible algo order is sent to the algo trading platform 320, the HERO system 310 generates a corresponding strategy order and submits the strategy order to a strategy matching venue 315. While one strategy matching venue 315 is shown, there may be multiple strategy matching venues available, 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 may be predefined or may be dynamically selected based on various factors, such as the type of tradable item being submitted or other details about the order.

[0086] The overall processing of strategy orders by the HERO system 310 and each strategy matching venue 315, and the processing of corresponding algo orders by the algo trading platform 320 and PIT venues, occur roughly in parallel. Strategy matching for a strategy order takes priority over the algorithmic processing of the corresponding algo order. Messages are exchanged between the HERO system 310 and the algo trading platform 320, with the HERO system 310 instructing the algo trading platform 320 to start and stop algorithmic processing of algo orders while streaming fills from strategy matching by the strategy matching venues. Messages are also exchanged to keep both the HERO system 310 and the algo trading platform 320 up to date regarding the status of filling each algo order and the corresponding strategy order.

[0087] The total number of executed shares resulting from a strategy match may be unknown at the time the match is made by strategy matching venue 315. When strategy matching venue 315 detects a match, it notifies HERO system 310 of the existence of a match-found condition message, also referred to herein as a "stream on" condition, for the associated strategy order. HERO system 310 then notifies algo trading platform 320 of the stream on condition, instructing algo trading platform 320 to stop slicing new child orders for the corresponding algo order.

[0088] When a stream of fills ends at a strategy matching venue 315, it sends a matching break condition message, also known as a "stream off" condition, to the HERO system 310 for the associated strategy order. The HERO system 310 is also notified by the strategy matching venue 315 of the total number of fills performed during the strategy match, including the total while fills were being performed at the strategy matching venue or after the stream ended. The HERO system 310 updates its internal records associated with the strategy order. It also notifies the algo trading platform 320 of the stream off condition and the total number of fills (if that information has not already been provided). The algo trading platform 320 can then update its own internal records for the corresponding algo order. If the algo order is not fully filled, the algo trading platform 320 can resume any remaining algorithm 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 may also be sent between Strategy Matching Venue 315, HERO System 310, and Algo Trading Platform 320 as needed to confirm conditional orders or to determine the amount of shares that can be exchanged for a given order. If a strategy order specifies a total number of shares, strategy order updates may be sent by HERO System 310 to Strategy Matching Venue 315 to reflect implementations resulting from the activities of the algo systems working the corresponding algo orders.

[0090] In one embodiment, because the HERO system 310 communicates with internal aspects of the algo trading platform 320, the HERO system module 310 may 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 and modify its algo order management, appropriately communicating with the HERO system and starting and stopping algorithmic order processing as needed. Such an algo system can then be controlled to pause and resume algorithmic processing of algorithmic orders in favor of processing corresponding orders in parallel with a separate order processing system that can fulfill the corresponding orders, in whole or in part, in a more efficient manner.

[0091] The algo trading platform system can also be designed or modified to have appropriate API or other programmatic hooks and internal controls required to work with the HERO system even if the HERO system is not initially available or is available but implemented as a separate system. A HERO system module with an appropriate API interface for communicating with the algo platform can be added separately. There are various ways in which the HERO system 310 can be implemented and integrated into a conventional algo trading platform 320. Specific embodiments are described below.

[0092] 4 is a high-level diagram of the architecture of the HERO system 315. One or more computer processors 405 execute computer software stored in program memory 410. The processors 405 have access to a data memory 412 that contains 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, used to generate strategy orders based on algorithmic orders.

[0093] An appropriate communications interface 430 is used to connect the HERO System 310 to external systems. In the illustrated embodiment, a LAN 435 provides communications between the HERO System 310 and the algo trading platform 320, while a separate WAN 440 provides communications 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 with sufficient data throughput and processing power to support the expected trading 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. Suitable computer platforms are known to those skilled in the art.

[0094] The program memory 410 and data memory 412 may be embodied, in whole or in part, in the same or different components. Memory 410, 420 may include one or more internal RAM and firmware, local electronic data storage such as a solid-state or magnetic drive, or external data storage provided by memory physically coupled via a USB or other data cable accessible over a network. Other computer-readable media for storing software and data may also be used. The HERO system 310 may be embodied in one or more computer servers, personal computers, or other computer systems.

[0095] A separate user interface 445 may be provided, allowing a computing device 450, such as a PC, to access the HERO system 310 and allow authorized users to perform various administrative functions such as monitoring HERO system performance metrics, viewing order maps and transaction history, adjusting system configuration, etc. The remote device 450 may connect to the HERO system 310 locally or through a network 455, such as an intranet or secure VPN over the Internet, to provide remote monitoring.

[0096] The HERO System 310 may be implemented as an internal computer system of a given broker-dealer system's infrastructure, and in one embodiment is implemented on the same physical computer as the algo trading platform 320, with the processor 405 executing both the algo and HERO system code and the program memory 410 storing the functionality 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 may be implemented at a lower level using various internal APIs or other messaging protocols known to those skilled in the art, and a separate LAN connection may not be required.

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

[0098] Multiple HERO systems operating in parallel can be used with algo trading platform 320. Load balancing and other techniques can be used to allocate appropriate algo orders to the HERO systems. Similarly, a broker-dealer with several internal algo order managers can integrate each with a common HERO system.

[0099] 5 is a high-level diagram illustrating functional aspects and data communications of one embodiment of the HERO System 310 (i) between the HERO System 310 and components of the algo trading platform 320 with HERO System-aware algo order management 580, and (ii) between the HERO System 310 and one or more respective strategy-level strategy matching venues 315. The internal functioning of one embodiment of the HERO System 310 and inter-system communications are described in more detail with reference to the flowcharts of FIGS. 7 and 8.

[0100] The illustrated HERO system 310 can track strategy orders, store their details in a strategy order table 415, and includes a strategy order management 505 that includes functionality primarily related to exchanging information and messages with the algo trading platform regarding algos and strategy orders. Note that the order quantities stored in the algo order table 120 and the strategy order table 415, while related to one another, need 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 to be made available for use in strategy orders. This difference can act as a buffer to prevent the risk of over-execution.

[0101] Communication between Strategy Order Management 505 and Strategy Matching Venues 315 may be supported by a Strategy SOR 510, which routes communication regarding strategy orders between Strategy Order Management 505 and one or more Strategy Matching Venues 315, and may have the functionality to select an appropriate Strategy Matching Venue if more than one is available. Although Strategy SOR 510 is shown separate from Strategy Order Management 505, the functionality may be combined into an integrated software program. Similarly, the functionality of Strategy Order Management 505 may be implemented in multiple software components.

[0102] Various messages can be sent between the HERO system 310 and each strategy matching venue 315. These messages include strategy orders 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 fill. Firm order and other firm-related messages 540 are used to process conditional strategy orders. Various message protocols can be used, such as the FIX (Financial Information Exchange) protocol.

[0103] Various messages can be sent between components of the HERO System 310 and 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 know of a variety of suitable message protocols.

[0104] When an algo or algo order update is received by algo trading platform 320, it can send an order update message 550 to the HERO system 310. As algo trading platform 320 places an algo order, information regarding the order status, such as back order quantity updates 565, can be sent to the HERO system 310 so that the HERO system remains informed of the number of shares for the corresponding strategy order available for strategy matching. As each 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 algo order management 580. Similarly, execution data 530 received from strategy matching venue 315 can be sent as an execution message 555 so that algo trading platform 320 can update its internal records regarding the corresponding algo order.

[0105] When the HERO System 310 detects or is notified of a new algo order, it can generate a corresponding strategy order. One way this can be done is through the Used Strategy Mapping Rules 420, with reference to FIG. 6. The Strategy Mapping Rules 420 can be predefined to reflect the various trading preferences of participating users. The mapping can be performed using any algo order details available to the process. Additional data can also be referenced. For example, the Supplemental Order Data field of the algo order 105 sent by the OMS / EMS 110 to the algo trading platform can be used to provide additional information for use by the Strategy Mapping Rules, for example, to directly specify a particular strategy.

[0106] Different institutional OMS / EMS 110 or broker dealers may have different choices regarding how to map algorithmic orders with various attributes to strategies in a given strategy pair. The provider of the algo trading platform 320 may define their own mapping rules for use with orders, or the user may define them. If more than one set of rules 420 is available, the HERO system can select the appropriate set of rules or which set to use.

[0107] In addition to the static one-to-one mapping described above, more intelligent dynamic rules can be defined to allow selection of a corresponding strategy based on information external to a particular algo order, such as current or historical market data 610. In the above example of a 12% capacity order, the transformation mapping could specify matching to a 10-30% strategy if a specified market condition exists, such as an index above its 30-day average, and matching to a 5-15% strategy if the condition does not exist. The HERO system can also operate to monitor relevant market data and responsively adjust strategies for existing strategy orders. If the strategies selected for existing strategy orders are allowed to change over time, the HERO system can periodically reevaluate the strategies for such strategy orders in the strategy order table, update the strategies as necessary, and send strategy order change messages to strategy matching venues as appropriate to reflect this change.

[0108] Strategy mapping rules need not allow mapping to every available strategy. Certain strategies, for example, strategies with base rates greater than 100%, may not fit the expected set of algorithmic constraints for algorithmic orders received by the algorithmic trading platform. Such unused strategies may still be specified in strategy orders placed in the Strategy Matching Venues by other 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 a different embodiment, the algo trading platform 320 may also generate corresponding strategy orders at that time and publish the strategy orders to the HERO system 310 as part of the process for adding new algo orders to the algo order table 120.

[0110] 7A and 7B are high-level flowcharts of the operation and completion of the HERO System-Aware Algo Order Management 580 for processing an algo order. For simplicity, the functionality is generally addressed to processing a single parent order. Various techniques for implementing the functionality 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 algo order is received (step 702), the order is added to the algo order table 120 and also sent to the HERO system 310. If a stream-on condition does not exist (step 706), a child slice is generated according to the particular algorithm in question and issued to the SOR 140 (steps 708-712) in a manner similar to the operation of the algo system 100 without the HERO system. The number of potential shares for the algo order is reduced. Data may also be provided to the HERO system 315 (step 714) reflecting changes in the available potential shares for the algo order, which may affect the quantity available for strategy matching. The slicing process continues until no potential shares remain (step 716).

[0112] If a stream-on condition exists (step 706), the child slicing process is suspended and Algo 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 filled can remain open, in which case they will eventually be filled. In an alternative embodiment, once a stream-on message is received, Algo Order Management 580 can cancel some or all of the unfilled child orders (step 718). Successfully canceled child orders decrease the number of potential shares and increase the number of shares available for strategy matching. The HERO system is notified of the success (or failure) of the cancellation and the associated change in the number of potential shares (step 720).

[0113] 7B illustrates a high-level function of a monitor process thread that processes execution notifications. When an execution notification is received from the algo trading platform SOR or the HERO system 130 (step 724), the appropriate values ​​for the corresponding order in the working algo orders table 120 are updated (step 726). When a cancel order request is received from the HERO system 130 (step 728), any outstanding child orders for the associated algo order are canceled (step 730), and a cancellation completion indication is provided, for example, to the HERO system 130 (step 732). Processing of the order is complete when all shares for the algo order have been fulfilled or an order termination condition has occurred and the order is canceled (step 734).

[0114] 8A-8C are high-level flowcharts of the operation of one embodiment of the HERO system in processing orders. For simplicity, functions are generally directed to processing a single order, and functions are shown as separate program engine threads A-E. The use of independently performing program threads is not required; functions of one or more threads can be combined. Those skilled in the art will know various techniques for implementing these functions in systems and methods for processing multiple independent orders.

[0115] Thread A 801 processes new algo orders. New algo orders can be detected, such as via messages sent by Algo Order Management 580, or by HERO System 310 monitoring of Algo Order Table 120, or via other data in the algo trading platform. If a minimum order size for strategy order processing is defined, the new algorithm order size is checked (step 802). If the algo order is larger than the predetermined minimum size, the associated strategy mapping rules are used to determine the strategy for the algo order. A new strategy order record with associated strategy order data is added to the strategy order table (steps 804, 806).

[0116] Thread B 811 determines when to issue a strategy order from strategy order table 415 to a strategy matching venue. A determination is made whether a strategy order that is not pending at the strategy matching venue is available, and optionally, whether other conditions, if defined, are met (step 812). If a strategy order is available, the appropriate strategy order is issued to the strategy matching venue (step 814), such as via strategy SOR 510. Preferably, HERO system 315 maintains a minimum buffer size and sends a strategy order to a strategy matching venue only if the number of potential shares for that strategy order exceeds the minimum buffer value. If a minimum order size is specified, strategy orders below the minimum size are no longer considered eligible.

[0117] Thread C 815 provides an order update function. When a message is received from algo order management 580 (or other aspects of algo trading platform 320) 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 filled, the appropriate record in strategy order table 415 for the corresponding strategy order is updated. The updated information may change the strategy selected for the corresponding strategy order as defined by the associated strategy mapping rules 420. In such a case, the strategy specified in strategy order table 415 is updated accordingly. If the strategy order in question is outstanding at strategy matching venue 315, a message may also be sent to the strategy matching venue to update the strategy for that order (step 818). When a data message reflecting a streaming execution is received from strategy matching venue 315, the data in the strategy order table for the associated strategy order is updated as necessary. The fulfillment data, including at least the order indicator and the amount fulfilled (eg, 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 venue 315 (step 824), a stream on condition for the respective order is sent to algo order management 580 (step 826). Depending on the implementation details, a signal may also be sent instructing algo order management 580 to cancel any outstanding child orders of the corresponding algo order, thereby making potential fills from those outstanding child orders available for strategy matching (step 828). When a stream off message is received from the strategy matching venue 315 (step 830), a stream off for the respective order is sent to algo order management 580 (step 832). Depending on implementation details, the stream off signal may be treated by Algo Order Management 580 as an instruction to resume slicing of new child orders for the corresponding algo order on its own, or an additional signal may be sent explicitly instructing Algo Order Management 580 to resume slicing of new child orders, thus allowing the HERO system to deal with trading scenarios where a stream off for a given strategy order is received but conditions do not guarantee resuming slicing 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 (step 834), such as would occur as a result of a child order for the corresponding algo order being filled, 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 may be canceled and deleted from the strategy order table 415 (step 842). If the associated strategy order is outstanding at the strategy matching venue 315, a message with the updated quantity available for the strategy order may be sent to the strategy matching venue 315.

[0120] Thread F843 is for processing aspects of conditional strategy orders. Conditional strategy orders issued by the HERO system 310 to the strategy matching venue 315 may include or omit the total number of shares available for the order. If the strategy matching venue detects a match, it may issue a request to the HERO system to confirm the conditional strategy order and provide a quantity value. When a confirmation request for a strategy order is received (step 844), 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 confirmation request, after the algo order child order cancellation process is completed, the HERO system may determine the available number of shares available for strategy matching based on the current potential number of shares, buffer size, and other factors (step 848) and send a confirmation response message to the strategy matching venue 315 (step 850). The definite response can be in the form of, for example, a non-conditional strategy order or a message. The non-conditional strategy order replaces the conditional strategy, and the message instructs the strategy matching venue 315 to update the conditional strategy order to non-conditional, and to change other aspects, such as the number of available shares, accordingly. The strategy matching venue 315 can keep the strategy match open until the order is confirmed. 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 confirmed, the strategy matching venue issues a stream on condition message.

[0121] 9A and 9B illustrate the processing of a sample parent algo order and corresponding strategy order for selling 100,000 shares by the HERO perceptual algo trading platform 320 and the HERO system 310, operating in parallel and showing the direction of propagation of various order-related data values ​​between the systems as processing progresses. In this example, the HERO system 310 is configured to maintain a buffer of 15K potential shares.

[0122] At time T0, all 100K shares of the parent order are potential before any action is taken. At T1, the first 5K of the child order are sliced ​​by Algo Order Management and issued to SOR 140, which subdivides them into grandchild orders that are issued to Trading Venues 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 orders are issued to the strategy matching venues.

[0123] At time T2, there are 5K shares for the algo child orders. 2K algo order fills are received, reducing the outstanding value to 3K. The 2K child orders are then sliced ​​and submitted to SOR 140, bringing the total number of submitted algo child order shares back to 5K and the number of potential shares back to 93K. The number of shares available for strategy matching is therefore reduced to 78K, and a strategy order update indicating the changed amount is submitted to the strategy matching venue. Time T3 shows the result of the 5K algo order fill, followed by the slicing of the 5K child orders, the reduction in the number of potential shares, and the subsequent update of the strategy order from 78K to 73K.

[0124] At time T4, the strategy matching venue finds a match for the strategy order and a stream-on condition exists. When a strategy matching venue stream is satisfied, it returns information about the number of fills. In this example, 30K streaming fills (which may be reflected in a sequence of smaller fills) are shown. The number of potential shares is reduced by 30K. There are also 5K child orders on the algo side.

[0125] At time T5, the algo system receives a fulfillment message indicating that 4K of the 5K outstanding child orders have been filled. The number of issued shares for the algo child order is now 1K. Because the child order has already been accounted for, the number of potential shares does not change. Due to the stream-on state, issuance of new child orders by the algo trading platform 320 is paused.

[0126] At time T6, an additional 43K streaming fills of the outstanding order are indicated, reducing the number of potential shares to 15K. The total number of streamed strategy matching fills reaches 73K, the current size of the strategy order. The strategy matching venue closes its order and a stream off condition is indicated.

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

[0128] 10A and 10B illustrate the processing of a sample parent algo order and corresponding strategy order to sell 100,000 shares by a HERO-aware algo trading platform 320 and a HERO system 310, operating in parallel and showing the direction of propagation of various order-related data values ​​between the systems as processing progresses. The example of FIG. 10 is similar to the example of FIGS. 9A-B, but uses an algo trading platform 320 configured to cancel outstanding child orders in response to receiving a stream-on indication from the HERO system, instead of allowing those orders to be filled.

[0129] System operation from times T0 to T3 is the same as in Figures 9A-9B. At time T4, in response to the stream-on condition, algo trading platform 320 cancels 5K of the outstanding child orders. The number of potential shares increases by 5K. Because 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 manner similar to that of Figures 9A-9B.

[0130] In some situations, the benefits provided by strategy order processing at a strategy matching venue may be desired, but a HERO system-enabled platform is not available at the broker / dealer to receive such orders. In a further aspect of the present invention, a Pre / Post Routing Optimizer (“PRO”) system may 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 processes the orders in a manner similar to the HERO system by generating corresponding strategy orders (if necessary) and sending them to a strategy matching venue. The OMS / EMS can also send the original orders to a conventional broker / dealer that processes them in its own algo system.

[0131] Because the PRO system is not coupled to the broker / dealer's algo system 100, the PRO system cannot signal to the algo system 100 to start or stop algorithmic processing of an algo order when a match for the corresponding strategy order is found, as indicated by a stream-on condition message. To compensate for this, issued strategy orders are conditional. If the strategy matching venue indicates that a strategy match is available for the strategy order, the PRO system can signal, for example, by sending a firm request, that the order placed in the broker / dealer's algo system should be canceled and the corresponding strategy order should then be firmed. After the strategy matching venue indicates that strategy matching has finished, for example, with a stream-off condition message or an indication that firming was not successful, the PRO system can signal that a new order 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 the various platform components as Algo and Strategy orders are processed so that the progress of order filling is tracked and order filling does not exceed the total order size.

[0132] 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, which comprises a PRO System Engine 1110 coupled to a Trade Order Management 1115. The OMS / EMS 1100 can receive orders placed by Portfolio Management 1120 via a Deal Desk 1125. The OMS / EMS 1100 communicates with brokers / dealers using conventional algorithmic trading systems 100, who place orders on conventional exchange venues 150, where the orders are filled against matching contra-orders placed by other market participants, such as other conventional brokers / dealers and HFT firms. The OMS / EMS 1100 also communicates with one or more Strategy Matching Venues 315, which can place strategy orders from the PRO System, which can be generated based on 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 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-enabled brokers / dealers 300, other PRO systems operating in conjunction with other OMS / EMS systems 1100', and any other suitable order source.

[0133] 12A and 12B are high-level diagrams illustrating functional aspects of one embodiment of the PRO System 1110 and the communications between (i) the PRO System Engine 1100 and the Strategy Matching Venue 315, and (ii) the PRO System and the PRO System Aware Trade Order Management 1115 in the OMS / EMS System 1100. The internal functionality of an embodiment of the PRO System 310 and inter-system communications will be discussed in more detail with respect to the flowcharts of FIGS.

[0134] Trade order management 1115 uses broker / dealer interface 1120 to communicate with one or more brokers / dealers using conventional and HERO System-enabled algorithmic trading engines 100. Messages that can be sent and received include submitting new algorithmic orders 1125 to a broker / dealer's algo trading platform 100, receiving messages related to the execution 1130 of placed algo orders 1125, and submitting requests 1135 for algo trading platform 100 to cancel or appropriately modify existing orders. OMS / EMS work order table 1105 is used by OMS / EMS 1100 to track outstanding orders.

[0135] The PRO 1110 comprises a Strategy Order Management 1140, a Strategy SOR 1145, and a Strategy Order Table 1150 for maintaining data regarding current strategy orders. In embodiments where one or more of the algo trading platforms available to the OMS / EMS 1100 are HERO system enabled, the OMS / EMS can indicate whether an order was sent to such an algo trading platform, and the PRO system is configured to only act on algo orders sent to non-HERO-aware algo trading platforms.

[0136] From the perspective of the strategy matching venue 315, the PRO system 1110 and the HERO system 310 may appear the same and may have the same types of message exchanges. Like the HERO system 310, the PRO system 1110 and the strategy matching venue 315 exchange messages related to strategy orders, including placing new conditional or non-conditional strategy orders, receiving stream on and stream off condition messages, receiving strategy order execution data, and confirming conditional orders.

[0137] The strategy SOR 1145 operates to route communication regarding strategy orders between the strategy order management 1140 and one or more strategy matching venues 315, and may also include functionality for selecting an appropriate strategy matching venue if more than one is available. Although the strategy SOR 1145 is shown separate from the strategy order management 1140, the functionality may be combined into an integrated software program. Similarly, the functionality of the strategy order management 1140 may be implemented in multiple software components.

[0138] Orders received at the OMS / EMS 1100 may be conventional orders intended to be processed by a conventional algorithmic trading system and may or may not specify a trading strategy. If no strategy is specified, a corresponding strategy order may be generated via a set of strategy mapping rules 155 in the same manner as described above with respect to the HERO system. This functionality may 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 the OMS / EMS 1100 to the PRO system 1110. Messages related to stream-on and stream-off conditions and strategy order streaming enforcement can be sent from the PRO system 1110 to the OMS / EMS 1100. Additionally, messages related to the cancellation or rerouting of algo and strategy orders can be exchanged between the PRO system 1110 and the OMS / EMS 1100.

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

[0141] A suitable communications interface 1180 is used to connect the PRO system 1110 to external systems. In the illustrated embodiment, a local area network provides communications between the PRO system 1110 and the OMS / EMS 1100, and a separate WAN provides communications 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 with sufficient data throughput and processing power to support the expected trading 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 data memory 1170 may be implemented, in whole or in part, in the same or different components. The memories 1156, 1170 may include one or more internal RAM and firmware, local electronic data storage such as a solid-state or magnetic drive, or external data storage provided by memory physically coupled via a USB or other data cable accessible over a network. Other computer-readable media for storing software and data may also be used. The PRO system 1110 may be implemented in one or more computer servers, personal computers, or other computer systems.

[0144] A separate user interface 1185 may be provided to allow a computing device 1190, such as a PC, to access the PRO system 1110, allowing authorized users to perform various administrative functions such as monitoring system performance metrics, viewing order maps and transaction history, and adjusting system configuration. The remote device 1190 may connect to the PRO system locally or may connect via a network such as an intranet or secure VPN over 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, perhaps even on the same physical computer as the trade order management 1115, in which case a separate network connection between the PRO System 1110 and other components within the OMS / EMS 1100 may not be required. The OMS / EMS can be designed or modified to have the appropriate API or other program hooks and internal controls required to operate with the PRO System even if the PRO System is not initially available or is available but implemented as a separate system. A separate PRO System module with an API interface suitable for communicating with the EMS / OMS can then be added. There are various ways in which the PRO System 1110 can be implemented and integrated with the EMS / OMS system 1100.

[0146] 13A and 13B are high-level flowcharts illustrating aspects of the operation of an embodiment of the PRO system engine in processing orders. For simplicity, the functions generally relate to the processing of a single order. Those skilled in the art will know various techniques for implementing these functions in systems and methods for processing multiple independent orders.

[0147] 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 amount exceeds a minimum value, the corresponding strategy order is issued as a conditional order to the strategy matching venue 315 (step 1314) for strategy matching to be used, if specified (step 1312). It is assumed that the initially received order will exceed the minimum value, although this may not be guaranteed.

[0148] As algo orders are processed, an execution update message is generated and sent to the PRO system. These executions affect the quantity available for the corresponding strategy order. In response to receiving 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 associated strategy matching venue. If the quantity available for the strategy order falls below a minimum, the PRO system can send an order cancellation message to the associated strategy matching venue 315 (step 1316).

[0149] After issuing a conditional strategy order, the PRO system waits to receive a confirmation request from the strategy matching venue (step 1318) as long as the strategy order is still open. If 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 trading order management 1115 instructing the broker / dealer to cancel the corresponding algo order (if any) sent to the broker / dealer (step 1320). After the algo order is successfully canceled, trading order management 1115 sends a message confirming the successful cancellation. The message may also indicate the maximum number of shares available for strategy matching, which should be less than or equal to the total unfilled portion of the original order. (The PRO may also, or instead, be configured to issue a query to the OMS / EMS 1100 requesting information about a particular 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, conditions may change at the strategy matching venue 315 such that a potential match can no longer be solidified. For example, a selected contrast latency order may be conditional but not confirmed within a timeout period. If the PRO system does not receive a stream-on indication for the order within the applicable timeout period (step 1326), the confirmed order is presumed not to be fulfilled. The strategy matching venue 315 may be configured to send a notification of the confirmed conditional strategy order to the issuer, indicating that the match failed. Receipt of such a message by the PRO system can be treated similarly to a timeout condition while waiting for the stream-on message. (Similar functionality can be implemented in the HERO system.)

[0151] After a timeout (step 1326), the OMS / EMS is notified that it can reissue the algo order (which is canceled in light of the firming 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 canceling the previously firmed order. The strategy order remains pending in the PRO system. If the quantity available for that order exceeds the minimum (step 1312), another conditional order can be placed and the process can continue.

[0152] If strategy order matching is performed at a strategy matching venue, the strategy matching venue can return the rate of the match (which may be only a fraction of the base rate available for the specified strategy). Additionally or alternatively, the strategy matching venue can determine the total fill resulting from the match, or at least the maximum amount of resulting fill (based on the rate used for strategy matching and the maximum available amount of matched orders). If this information is available, it can be included as part of the stream-on message. If the PRO system receives a stream-on in a timely manner after finalizing a conditional strategy order, and the stream-on message indicates the expected amount of fill from that match or provides data from which that information can be derived, the PRO system can calculate the amount of strategy order remaining after the strategy matching streaming is complete. If the strategy matching does not satisfy the maximum amount available for the strategy order in question, efforts to fill the remainder of the algo-side orders can proceed without conflicting with the strategy order fill. In such a case, the PRO system can notify the OMS / EMS to issue an algo order that seeks the difference between the maximum quantity available for the strategy order and the actual or maximum quantity expected to be filled at the strategy matching venue (steps 1330, 1332).

[0153] Subsequently, after stream-on, a fulfillment message for the strategy order is received at the PRO system from the strategy matching venue (step 1334). The fulfillment data is sent by the PRO system to the OMS / EMS (step 1336), which can use this data to update its internal records to reflect the fill that occurred. This continues until a stream-off message for the strategy order is received (step 1338). The OMS / EMS is then instructed to reissue the canceled algo order to the broker / dealer for the remaining unfilled order quantity (step 1340).

[0154] 14A and 14B show high-level functional block diagrams of a specific 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, which can include strategy SORs such as those used in the HERO or PRO systems, traditional SORs, and any other sources of suitable orders, such as directly placed strategy orders originating from a broker gateway. 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, firm commands, and other communications can be sent over this interface. Minor extensions to the FIX protocol, such as defining new FIX message values, may be required to support features such as stream on / off messages and new strategy order types.

[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 may be sent to a strategy order generator engine 1430, which converts the non-strategy orders into strategy orders. A set of one or more default strategies 1435 may be provided and selected according to a predetermined set of rules. Strategy selection may depend on the content of the non-strategy order and / or its source or other data. One broker / dealer may define liquidity search as the default strategy to use for any non-strategy orders it sends, while different brokers / dealers may request different strategies. It is also possible to use more complex systems for selecting strategies such as those used within the HERO system 315 and described above. Although the strategy order transformation is shown as part of the strategy matching venue 1400, the strategy selection engine using predetermined strategy mapping rules 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 transactions, from an appropriate Security Information Processor (SIP) 1415, or the like. Two or more data sources may be available for use within the strategy matching venue 1400, such as from alternative market (or non-market) data sources 1425. 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. Execution reports are returned to the appropriate order router 1410 via 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 functionality in Strategy Matching Venue 1400 is implemented in software, which may be organized as a set of software engines. I / O Handler 1405 processes input and output messages and updates data records related to incoming orders. SIP Handler 1445 receives input market and other data and routes the relevant data to the appropriate internal engines, such as by sending first market data, which may be an NBBO quote, to Quote Handler 1450 and second market data, which may be an individual market execution notice for the item being traded, to Trade Handler 1455. In one embodiment, Quote Handler 1450 examines the input data and determines whether a pending strategy order is marketable and therefore actionable. Trade Handler 1455 processes input SIP data related to market transactions, e.g., the amount of the security being traded, so that the information is available for use by Trade Processor 1465. Matching Engine 1460 identifies eligible matches among pending strategy orders. Trade Processor 1465 is a streaming engine that generates trades for matched strategy orders.

[0158] Referring to FIG. 14B, the strategy matching venue 1400 can be implemented in a computer system, such as a suitable server, connected to one or more processors 1470 and storage devices 1440, which can include internal RAM and firmware, local electronic data storage such as solid-state or magnetic drives, and external data storage provided by memory physically coupled via a USB or other data cable accessible over a network. Program memory 1472 is used to store executable computer software executed by the processor. 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 operation of the system. Suitable interfaces are provided for communicating with external systems. For example, an order interface module 1480 can be used to communicate with various order routers or other order sources 1410 over an order network 1482. A market data interface module 1484 can be used to access various sources of market data 1415, 1425 over a market data network 1486 to retrieve market data used during order processing. A trade reporting interface module 1488 may be used to provide performance information to a trade reporting facility 1420 via an appropriate reporting network 1490 .

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

[0160] FIG. 15 illustrates 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 data structures 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 to reference the contents may be changed. The various data tables and objects may be stored in memory storage area 1440, which may consist of various types of storage, such as local RAM, solid-state drives, cloud storage, etc.

[0161] In the data arrangement of FIG. 15, three primary data arrays (which may be organized and referenced in storage as data tables, database objects, or in other ways) are provided and appropriately stored in memory 1440 of strategy matching venue 1400.

[0162] All Orders 1502 is used to store information about active strategy orders placed in Strategy Matching Venue 1400. Each order record has a unique order ID and stores strategy order information with symbol, side, and limit price. A conditional flag indicates whether the order is conditional. The order amount specifies the number of shares (or other tradable item) in the order that are available for strategy matching. The strategy type field stores the strategy used for the order. Over time, the available share amount changes as strategy orders are processed or updated.

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

[0164] The marketability flag indicates whether market conditions associated with an order make the order marketable. For example, if an order is to buy a security, the order is not marketable if the current trading price of that security is greater than the limit price of the order. 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 matching contra-order at that time.

[0165] Streams are data arrays within the All Orders table that are used to indicate which stream or streams (if any) each order is related to. A large order may, for example, be matched to two smaller orders resulting in two transaction 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 a contra-order.

[0167] Orders may be defined so that the strategies applied to them can be dynamically changed in response to changing market conditions for conditional alternative strategies. In certain embodiments, orders provide a way for an attribute of an order, such as a limit price, to specify that its strategy should be changed if the current quote for the security in question exceeds a specified limit. For example, a 5-15% strategy buy order may have a regular limit price of $15.75 and a limit price of $15.65. If the security's offer price exceeds the limit price, the offer is not marketable. If the current offer is between the two prices, the order is marketable and uses the 5-15% strategy. If the offer price falls below the limit price, the order strategy can change to a different strategy, such as liquidity search, or to a user-specified secondary strategy for the order. If a limit price is provided but no secondary strategy is specified, a default strategy, such as liquidity search, can be used. Strategy adjustments can be made when an order is examined to determine whether it is marketable. A flag may be provided to indicate whether this feature is enabled for a given order. Alternatively, the limit price may be set to zero by default, with a non-zero value indicating the feature is enabled. This or similar conditional strategy feature may be implemented in the HERO or PRO system as an alternative to implementation in the strategy matching venue 1400, or in a first conditional strategy change process implemented in the HERO or PRO system, for example, and a second conditional strategy process implemented within the strategy matching venue 1400.

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

[0169] Instead of, or in addition to, including a second strategy in the strategy order itself, the issuer of the strategy order, such as the HERO system or PRO system, can monitor market conditions and detect when a strategy shift for a particular order may be needed. In response, the existing strategy order can be canceled and replaced with a substitute order having the 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 updates its internal records for the order accordingly and suspends or modifies existing matching as appropriate.

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

[0171] The arrival time may 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 about currently active order matches. Each record in an active stream can include data associating the initial order with one or more currently matched contra-orders. To enable easy lookup of matches for buy or sell orders, the table or data structure is indexed twice: once for buy orders and once for sell orders. Additional data can also be indexed. For example, matched orders can be indexed by security at issue time to easily identify active matches for a given security. In certain embodiments, each entry associates the first order with one matched contra-order. If an initial order is simultaneously matched with multiple contra-orders, there will be multiple entries for the initial order. A status field may also be included to indicate whether the stream is active (unbroken) or terminated. Information about terminated streams can be retained and / or archived in the active stream for a period of time, for example, for historical analysis and audit purposes.

[0173] The Unprocessed Reference Trades table 1506 is used to temporarily store market trades from the Trade Handler 1455 that have not yet been processed by the Trade Processor Streaming Engine 1465. Once the Trade Processor has processed a market trade from this table, it can be removed from this table and archived.

[0174] 16A-16C are high-level flowcharts of the basic functionality provided by embodiments of I / O Handler 1405, Trade Handler 1455, and Quote Handler 1450, respectively.

[0175] Referring to Figure 16A, when an input order message is received by the I / O handler 1405 (step 1602), it is checked to see if a strategy has been specified (step 1604). If no strategy is present, one is selected, for example, by using the strategy order generator engine 1430 (steps 1606, 1608). For received messages containing new orders or updates to existing orders, the full order table 1502 is updated to add the new order or change data stored for the existing order, as appropriate (steps 1602, 1604, 1610). When the I / O handler receives an output message for a client, such as a stream on / off condition message, an implementation message, or a confirmation request (step 1612), the message is formatted as necessary and then sent to the designated recipient, for example, via the FIX interface.

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

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

[0178] When a strategy order that is part of an active stream switches from marketable to unmarketable, the order is no longer eligible for matching. When the transition from marketable to unmarketable occurs, the market handler 1450 can check the active stream data for the order. If the order participates in one or more streams, a notification can be issued to break the order's matching and halt trading (step 1636). Because an order may be unmarketable for only a short, temporary period, after which marketability quickly returns, the match is temporarily saved (but not acted upon for enforcement purposes), and the match can only be broken if it remains unmarketable for longer than the specified period.

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

[0180] Enabling the use of a general marketability function in an automated trading system provides traders with additional flexibility to control whether additional orders are executed. While the marketability function will likely rely on bid / ask data for the tradable item in question, marketability functions based on additional and / or alternative data can instead be used. This may be appropriate to support trading of non-traditional tradable items and / or as an additional way to conditionally modify trading strategies. In certain embodiments, the function that sets an order's marketability flag (and thus prevents new matches) may be different from the marketability function applied in determining to break an existing match. The match-breaking marketability function may be state-based (as opposed to stateless) and may be based on previous activity or lack thereof. For example, the system may track how long or how much traded or how much the price moved during the period of no execution when determining whether to break an existing match.

[0181] Additions to the FIX protocol may be required to allow additional marketability conditions to be specified or to allow for 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] 17 is a high-level flowchart of an embodiment of a matching engine 1460 that implements a strategy matching process. The matching process may be performed continuously, periodically, or intermittently.

[0183] When the matching process begins, a strategy order A is selected from the full order book, for example. The selected strategy order A must be marketable and have available capacity to support matching (e.g., tradeable) (step 1702). There may be multiple orders for a given security and side that meet these criteria, from which strategy order A can be selected. Various methods can be used in prioritizing the selected orders. Orders can be ranked by order size, marketability, cost, or other factors, or a combination of two or more factors. Different ranking options can be provided for use with orders from different sources. A priority field can be provided within an order to allow the order placer to specify a selection prioritization factor, at least among orders from the same initial trader. Large orders over a threshold size, such as 100,000 shares, are prioritized higher than smaller orders, and can then be further prioritized, for example, according to when they were placed. Various other factors may also be used, such as if the order is new, or if the order has previously been matched but is not currently a match, and whether the order is an active match.

[0184] The matching process can also filter orders for consideration using other criteria. In one embodiment, an input order may indicate a preference for a broker or other source identifier or a specific subset of order characteristics. While all orders may be stored in a common overall order book, separate instances of the order matching process may be applied, each of which considers orders placed only by a specified source. Orders from different sources may be prioritized using different methodologies, which may be selected from a predetermined set of provided methodologies or ranking functions, such as when an account with a strategy matching venue is established. Indexing of available liquidity and factorization of other dimensions advantageously enable uniquely customized order priority books and liquidity searches.

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

[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 are applied can vary depending on preference or design choice. For example, orders may be prioritized first according to order size and then by strategy type, or vice versa. Other factors, such as those discussed above with respect to 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, when multiple potential contra-order matches with the same strategy are available, the matching engine may select an order from that strategy bucket using a sequence of prioritization factors that may include, in order of highest to lowest priority, order target strategy, order attribute preference, dormant order placement agency, original quantity of the order, order arrival time, and remaining order quantity (for new and conditional orders only).

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

[0189] The prioritized selection of contrast latent orders can continue as long as Order A has available capacity for additional contrast matching.

[0190] Returning to FIG. 17, if a matching contra-order B is not available for the selected order A and there are additional orders in the full order book to check (step 1708), the next available order A is selected using an appropriate prioritization method (step 1720), and the process continues until all relevant orders have been checked.

[0191] If 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 match between Order A and Order B is stored in the active stream table (1726). Orders A and B each have their own rate capacity based on the selected strategy and other strategies matched to them. For this match, the maximum rate that can be satisfied is the smaller of A's and B's available rate capacities. The available capacities of Orders A and B are reduced by this amount (step 1728). Stream On messages can then be triggered and sent to the sources of Orders A and B (step 1730). For liquidity search orders, matching does not affect the rate. However, matching can result in a maximum potential trading quantity (e.g., the lesser of the total quantity available for Order A and the total quantity available for Order B). This amount can be used to determine at least the minimum quantity for the liquidity search order that remains available for strategy matching with another contra order. If both Order A and Order B have liquidity search strategies, the match will result in a subsequent block trade being executed for the smaller of the total quantities available for Order A and Order B. Because the match can be executed at a determined price, such as the mid-price based on the current NBBO, and neither order in the pair is rate constrained, there is no need to participate in the streaming execution process executed in the trade processor streaming engine 1465. Alternatively, LS-to-LS matching can be processed by the trade processor streaming engine 1465 along with other matches.

[0192] Beneficially, the matching logic maximizes liquidity flow. If an order has capacity to receive a higher rate (or the liquidity search order has additional volume remaining), it is eligible for more matches. A large-volume order A can simultaneously match against multiple orders B, B', B'', etc. with smaller capacity, and the strategies of orders B, B', B'', etc. in multiple matching situations need not be the same.

[0193] If a stream on message for Order A is sent following a match with Order B, then if Order A matches a second Order B' while the match with Order B is still active, no additional stream on messages need to be sent. Similarly, a stream off message for Order A does not need to be sent until all active matches with A have ended.

[0194] A stream on message may be sent for each match if the stream on message contains additional information, such as the expected rate of the match or the maximum quantity that can be met during that match. A stream off message may optionally be sent when a match breaks, even if other matches exist. A receiving HERO or PRO system may independently track stream on and stream off messages for a given strategy order, such as by referencing the match ID contained 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 are no active matches for that strategy order. Alternatively, or in addition, a strategy matching venue may have two types of Stream Off messages, differing, for example, by the value of the message's Matches Remaining flag. The set value of the Matches Remaining flag indicates that there is at least one remaining non-consecutive match for the respective strategy order. If a Stream Off message is received but an active strategy for that strategy order remains, the Stream Off message may be considered by the receiving HERO or PRO system as purely informational and not used to trigger a notification to the algo trading platform to resume algorithmic processing or a notification to the OMS / EMS to reissue the algo order (for any remaining amount).

[0196] Returning to Figure 17, if one or both of the selected order A and the matching contra-order B are conditional orders (step 1722), then the order confirmation process is initiated for the conditional order (step 1732). As described above, this involves sending a confirmation request for the conditional order and may include switching the matched conditional order to a confirmed non-conditional replacement order. While the order is waiting to be confirmed, the process of searching for additional matches can continue (step 1708).

[0197] Each match or conditional match can be assigned a respective Match ID. The Confirm Request message can include the Match ID value of the conditional match at the time of issuance, and the returned Confirm Order response can include the associated Match ID value. The presence of the Match ID value in an order sent to the Strategy Matching Venue can be used to determine whether the match is a confirmation of an existing conditional order or a confirm, non-conditional order instead.

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

[0199] A strategy order can also have a "lifetime" specifier: if the lifetime is exceeded and the strategy order is still active, it can be cancelled and returned.

[0200] 18 is a high-level flowchart of an embodiment of the Trade Processor 1465. The Trade Processor 1465 operates based on market trade data provided by the Trade Handler 1455, and a trading cycle may be initiated upon receipt of new trade data or as trade data is buffered. Upon receiving trade data for a given security X at a trade volume V (which specifies the trade amount) and price P (step 1802), a check is made to see if there is an active stream order for security X (step 1804). If there is not, no further action need be taken for that data point.

[0201] If there are one or more active streams, for example, if there is an active match between Order A and ContraOrder B for Security X, those streams are processed (step 1804). For the selected stream, a check is made to determine if the price P is compatible with the limit price specified for the matched pair of Order A and Order B in that stream (step 1806). If the prices are incompatible, no further 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 of a pair of matched orders in one or more active streams (Order A can match Order B, and can also match Orders B', B'', etc.), an execution for the pair is generated (step 1816). In one embodiment, the execution is based on the amount of security X and the largest strategy basis compatible with the matched order's strategy. The streaming volume is the last sale volume V multiplied by the strategy basis percentage of volume, created at the last sale price. If the calculated streaming volume exceeds the available basis for one of the orders in the pair, the exchanged volume will be the lowest available basis. If one order has a liquidity search strategy, the highest percentage of available capacity for the other order's strategy will be applied. If both orders in the pair are seeking liquidity, a block exchange can be performed with a quantity equal to the lowest available quantity capacity of the two orders (in the case of a match between two liquidity search orders, the matched pair will be addressed in the trade processing loop). (This can be done at the time of matching, without waiting for the match to be completed.)

[0203] Streaming exchanges may be executed in a single transaction or split into several smaller transactions. Multiple market transactions may also be combined into a single strategy matching fill. Fills are executed using conventional techniques, and execution data is reported, for example, to an appropriate trade reporting facility 1420.

[0204] In a more specific embodiment, for price reference streaming matching, the system can continuously process the SIP deal feed and generate fills for each order in the match for all reference deals for the matched order as follows: 1. Calculate the cross quantity based on the strategy of each order in matching quantity and residual quantity (for example, if the strategy is both 100%~200%, the cross quantity is the smaller of twice the quantity of the base trade and the minimum of the residual quantity of the two sides of the match). 2. Calculate the cross price (CrossPrice) based on the base transaction price and applicable pricing rules. 3. Generate a cross quantity @ cross price (crossQty@crossPrice) execution for each matching order (decreases the remaining quantity for each order) and send a fixed execution report for each order. 4. Generate a report to the TRF including all other relevant details (e.g., associated MPID, risk-free principal, and other trade modifiers) as well as a clearing report to the DTCC. 5. If this implementation completes the order (i.e., remaining quantity = 0), it calls the completed order function, which results in a stream off message being sent and other relevant housekeeping being performed. Orders with remaining quantity continue to be processed by the matching system for subsequent matching and filling.

[0205] While the structural advantages inherent in the execution of the reference market and the universal segmentation applied in strategy matching venues protect investors, additional protections, such as anti-gaming features, can be added to further protect against the leakage of execution information. One way to do this is to introduce random factors into trading. These can include, for example, randomizing the matching rate when the stream is bidirectional, changing the stream rate intrastream, randomly rounding stream amounts up or down when referencing odd lots, periodic bunching of reports, and randomizing trade reporting.

[0206] Returning to Figure 18, after the exchange is complete, a determination is made as to whether one or both orders of the active stream pair have filled their available capacity (step 1820). If so, no further transactions are available for that pair, and matching is broken (step 1822). Order completion housekeeping tasks may also be performed, potentially resulting in other streams for that order being terminated. If additional capacity remains, matching continues and further exchanges can occur after additional relevant transaction data for the security in question is received.

[0207] If additional active streams of the paired order are available for that security X (step 1810), the next stream is selected and processed in the same manner (step 1812). After all of the active streams for security X have been processed, no further action is required with respect to these transactions by the transaction processor until another item of transaction data for security X is received.

[0208] In summary, once a match is established, a stream of execution flows from seller to buyer based on the match's strategy type. Match-making and break conditions are designed to minimize breaking of established matches. In one embodiment, a match / stream is terminated only when one or both orders become unmarketable based on the applied marketability test, one or both orders are completed (e.g., when the remaining quantity reaches zero, or one or both orders are canceled). In embodiments that prioritize blocking trades over streaming fills, a match can also be broken if one of the orders in the match is a liquidity search and a new, larger liquidity search-contra-side matching order arrives.

[0209] As described above, a match can be broken if one of the matches becomes unmarketable. An order can also lose marketability and immediately return to marketability. Instead of immediately breaking a match, the match can be suspended for a given buffer period before the match is suspended to preserve the pairing. If marketability returns to the order during the buffer period, the match is reactivated. Various conditions can be set to determine when a suspended match should be broken.

[0210] In certain embodiments, one or more of the following conditions are enforced: (a) the order remains unmarketable for longer than a specified timeout period, (b) the matching orders trade more than a specified market amount, such as 50K, in the security of the matched orders before both become marketable again, and (c) the market price (e.g., as specified in the NBBO market data) moves beyond the limit price by more than a certain amount, such as a specified price delta in the basis point, and the match is broken.

[0211] The strategy matching and streaming implementation method is flexible and can be applied to implement asymmetric trading strategies. As shown in FIG. 16D, the marketability function of an order can be defined based on any desired data available to the strategy matching venue. This can provide more control over when an order is actually matched. Similarly, special strategies can be defined that have an implementation quantity function based on factors in addition to, or instead of, the current quantity of the security being exchanged. This allows the strategy matching venue to 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 noted above, various extensions to the FIX protocol can be made to support the features of the present invention. Similar features can be implemented in other protocols that can be 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 functionality and management.

[0213] 7A, 7B, 8A-C, 13A, and 13B are high-level flowcharts of the operation of embodiments of the HERO-aware algo trading platform 320, the HERO system 315, and the PRO system 1110, focusing on functionality used to process a single parent order. Various methods of implementing this functionality to support the processing of multiple orders simultaneously will be known to those skilled in the art. The functionality illustrated herein can be performed continuously, periodically, or in response to software events or other signals. Conventionally, various orders have unique order IDs, and messages sent between the system and software elements include the appropriate order ID to associate those messages with their respective orders. Various other conventional bookkeeping and function management features can also be used.

[0214] Various functions disclosed in the flowcharts are shown as separate program threads. While multi-threaded programs may be used, they are not required, and software implementing such functions may be organized in a variety of ways, as known to those skilled in the art. Similarly, certain functions disclosed as occurring sequentially may instead be implemented in separate threads operating in parallel. For example, the transaction processor 1465 may cycle through active associated streams as new transaction data is received. This type of sequential function may also be implemented in parallel threads, with each thread processing one or more active streams and / or processing streams for different security purposes in response to receipt of transaction data for that security purpose.

[0215] Although the present system has been described as applied to systems and methods for trading securities such as stocks, index shares, etc., the strategy matching system may also be applied to processing or ordering other tradable items by reference to relevant market data for those tradable items. First market data is used to determine whether a given strategy order has marketability, and second market data is used to determine the timing and amount of streaming trades.

[0216] In further embodiments, strategy matching can support matching with only partial rate matching. In such cases, even considering the stream of matches provided by the strategy matching venue, there may still be additional rate capacity available for the order. In such cases, the algo processing system may be further controlled to slice the order using algorithm constraints modified to take into account the strategy order rate matching, so that the algorithm processing attempts to match differential rates not covered by the strategy matching venue.

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

Claims

1. 1. A method for processing trades of tradable items in an automated trading system, the automated trading system having a strategy matching venue operative to fill strategy orders, each strategy being a member of a predetermined set of strategies, each strategy having a base rate or a range of base rates, the strategy matching venue matching received strategy orders with strategy orders having strategies compatible with the received strategies, and generating a stream of executions of the matched strategy orders at a maximum rate compatible with the strategy of each matched strategy order and a contrast rate order, the method being implemented by one or more computer processors in the automated trading system, the method comprising: receiving a trade order for a tradable item specifying a side and an aggregate quantity, said trade order having associated algorithmic constraints; continuously generating sub-orders from the trading order in accordance with the algorithmic constraints and issuing the sub-orders to point-in-time (PIT) trading venues, each sub-order specifying a respective sub-order quantity; receiving PIT fulfillment messages from the PIT trading venue, each PIT fulfillment message corresponding to a respective sub-order and specifying a fill amount for each of the sub-orders, the fill amount being less than or equal to the respective sub-order amount; applying the algorithm constraints to a set of strategy mapping rules to select a first strategy from the predetermined set of strategies; generating a first strategy order corresponding to the trade order, the first strategy order specifying the tradable item, the side, and the first strategy; issuing the first strategy order to the strategy matching venue; receiving a matching detection condition message for the first strategy order from the strategy matching venue; halting the step of intermittently generating sub-orders for the first strategy order in response to the matching detection condition; receiving a plurality of strategy implementation messages for the first strategy order from the strategy matching venue, each strategy implementation message indicating a respective fill amount for the first strategy order; the match detection condition signals that the first strategy order matches a contrast latitude order of the tradable item; The method wherein the trade order is completed if the sum of the fill amount specified in the received PIT implementation message and the fill amount specified in the received strategy implementation message is equal to the total amount.

2. The method of claim 1 , further comprising canceling an unfulfilled suborder in response to the match detection condition.

3. receiving a matching termination condition message from the strategy matching venue indicating that the first strategy order does not match any contrast latency order; 2. The method of claim 1, further comprising: resuming the step of intermittently generating sub-orders in response to the matching termination condition while there is at least one potential share available for the trade order.

4. receiving a confirmation message from the strategy matching venue for the first strategy order; In response to receiving the confirmation message, determine the number of potential shares available for the trade order and send a confirmation response to the strategy match indicating a strategy order quantity less than the potential share.

10. The method of claim 1, further comprising: transmitting the information to a receiving venue.

5. 5. The method of claim 4, wherein the strategy order amount is the number of potential shares minus a predetermined buffer value.

6. 5. The method of claim 4, wherein the definite response comprises a second strategy order, the second strategy order specifying the tradable item, side, first strategy, and further specifying the strategy order quantity, the second strategy order having a link to the first strategy order.

7. detecting a confirmation failure condition if a matching detection condition message is not received from the strategy matching venue for the first strategy order within a predetermined timeout period after sending the confirmation response; 10. The method of claim 6, further comprising: in response to a firming failure, reissuing the canceled portion of the first trade order to the algorithmic trading platform.

8. The method of claim 4 , further comprising the step of canceling any outstanding suborders in response to receiving the confirmation message and before determining the number of potential shares.

9. 2. The method of claim 1, further comprising selecting the set of strategy mapping rules from a plurality of sets of pre-defined mapping rules based on attributes of the trading order.

10. 10. The method of claim 9, wherein the attribute of the trade order is the source of the trade order.

11. 2. The method of claim 1, further comprising: storing information about the trade order in an algo order table in a memory of the automated security trading system; and storing information about the first strategy order in a strategy order table in the memory.

12. 2. The method of claim 1, further comprising: in response to detecting a predetermined market condition, changing the strategy of the first strategy order from the first strategy to a second strategy.

13. 13. The method of claim 12, further comprising notifying the second strategy of the strategy matching venue of the change in the first strategy order.

14. 13. The method of claim 12, wherein the predetermined market condition comprises a change between a trading price for the security and a limit price for the first strategy order exceeding a predetermined threshold.

15. 2. The method of claim 1, wherein the tradable item is a security and the predetermined set of strategies includes a first strategy having a base rate range between R1 and R2 (R2>R1) and a second strategy having a base rate range between R3 and R4 (R4>R2 and R1<=R3<=R2).

16. 1. A system for processing trade orders placed with a trading network, the trade orders specifying tradable items, sides, and total quantities and having associated algorithmic constraints, the trading network having a strategy matching venue operable to fulfill strategy orders, each having a strategy that is a member of a predetermined set of strategies, each strategy of the predetermined pair of strategies having a base rate or a range of base rates, the strategy matching venue operable to match received strategy orders with contrasting latitude orders having a strategy and a strategy order compatible with the strategy of the received strategy order, and to generate a stream of executions for the matched strategy orders at a maximum rate compatible with each matched strategy order and the strategy of the contrasting latitude order, the system comprising: a memory having computer instructions stored thereon; at least one processor coupled to said memory for executing said computer instructions; The computer instructions include: (i) Equipped with an algorithmic trading engine; The algorithmic trading engine includes: code for receiving the placed trade order; code for intermittently (a) generating sub-orders according to algorithmic constraints, each sub-order specifying a respective sub-order quantity; (b) submitting each sub-order to a point-in-time (PIT) trading venue; and (c) receiving fulfillment messages from the PIT trading venue, each PIT fulfillment message corresponding to a respective sub-order and indicating a fill quantity for the sub-order, the fill quantity being less than or equal to the respective sub-order quantity; code for pausing generation of sub-orders in response to a pause signal from the rate optimization engine; (ii) the rate optimization engine: code for detecting a new order event indicating receipt of the placed trade order by the algorithmic trading engine; code for applying the algorithm constraints to a set of strategy mapping rules stored in the memory in response to the new order event to select a first strategy from the predetermined set of strategies; code for generating a first strategy order corresponding to the trade order, the first strategy order specifying the tradable item, a side, and the first strategy; code for issuing the first strategy to the strategy matching venue; code for receiving a matching detection condition message for the first strategy order from the strategy matching venue; code for issuing the pause signal to the algorithmic trading engine in response to the match detection condition message to pause generation of sub-orders for the trading order; code for receiving a plurality of strategy implementation messages for the first strategy order from the strategy matching venue, each strategy implementation message indicating a respective fill amount for the first strategy order; code for notifying the algorithmic trading engine of each fill amount in response to receiving each strategy implementation message; the match detection condition signal indicates that the first strategy order has matched a contrast latitude order for the tradable item; The trading order is completed when the sum of the fill amount specified in the received PIT implementation message and the fill amount specified in the received strategy implementation message equals the total amount.

17. further comprising a first data interface and a second data interface; 17. The system of claim 16, wherein the computer instructions for the rate optimization engine further comprise: code for communicating with the algorithmic trading engine using the first data interface; and code for communicating with the strategy matching venue using the second data interface.

18. the computer instructions for the algorithmic trading engine further comprise code for canceling a sub-order in response to a cancel signal from the rate optimization engine; 17. The system of claim 16, wherein the computer instructions for the rate optimization engine further comprise code for, in response to the match detection condition, issuing the cancel signal to signal the algorithmic trading engine to cancel outstanding suborders of the trading order.

19. the computer instructions for the algorithmic trading engine further comprise code for resuming generation of sub-orders in response to a resume control signal from the rate optimization engine; The computer instructions for the rate optimization engine include: code for receiving a matching termination condition message from the strategy matching venue indicating that the first strategy order does not match a contrast latency order; 17. The system of claim 16, further comprising: a code for issuing the resume in response to the matching termination condition to notify the algorithmic trading engine that it may resume generating sub-orders for the trading order.

20. The computer instructions for the rate optimization engine include: code for receiving a confirmation message from the strategy matching venue for the first strategy order; 17. The system of claim 16, further comprising: code for, in response to receiving the message, determining a number of potential shares available for the trade order and sending a firm response to the strategy matching venue indicating a strategy order quantity that is less than the number of potential shares.

21. 21. The system of claim 20, wherein the computer instructions for the rate optimization engine further comprise code for determining the number of potential shares by issuing a request to the algorithmic trading engine for status information regarding the trade order and receiving response status information from the algorithmic trading engine.

22. 21. The system of claim 20, wherein the strategy order amount is a potential number of shares minus a predetermined buffer value.

23. 21. The system of claim 20, wherein the definite response comprises a second strategy order, the second strategy order specifying the tradable item, side, and first strategy, and further specifying the strategy order quantity, the second strategy order being linked to the first strategy order.

24. the computer instructions for the algorithmic trading engine further comprise code for canceling a sub-order in response to a cancel signal from the rate optimization engine; 21. The system of claim 20, wherein the rate optimization engine computer instructions further comprise code for, in response to receiving the confirmation message, issuing the cancel signal to the algorithmic processing engine to cancel outstanding suborders prior to determining the potential number of shares.

25. 17. The system of claim 16, wherein the computer instructions for the rate optimization engine further comprise code for selecting a set of strategy mapping rules from a plurality of sets of predefined mapping rules based on attributes of the trading order.

26. 26. The system of claim 25, wherein the attribute of the trade order is the source of the trade order.

27. 17. The system of claim 16, wherein the computer instructions for the rate optimization engine further comprise code for changing the strategy in the first strategy order from the first strategy to a second strategy in the predetermined set of strategies in response to detecting a predetermined market condition.

28. 28. The system of claim 27, wherein the computer instructions for the rate optimization engine further comprise code for notifying the strategy matching venue of the change in the first strategy order to the second strategy.

29. 28. The system of claim 27, wherein the predetermined market condition comprises a variance between the trading price of the security and the limit price of the first strategy order exceeding a predetermined threshold.

30. 28. The system of claim 27, wherein the tradable item is a security and the predetermined set of strategies includes a first strategy having a base rate between R1 and R2 (R2>R1) and a second strategy having a base rate between R3 and R4 (R4>R2 and R1<=R3<=R2).

31. 1. A method of processing trades for tradable items in an automated trading system, the automated trading system comprising: an algorithmic trading platform operative to receive a trade order specifying each side, quantity, and associated algorithmic constraints, generate a plurality of discrete smaller sub-orders in accordance with the algorithmic constraints, and fulfill the received trade order by submitting the sub-orders to a point-in-time trading venue for execution; the automated trading system further comprising a strategy matching venue operative to fulfill each strategy, each strategy being a strategy member of a predetermined set of strategies, each strategy having a base rate or range of base rates; the strategy matching venue matching received strategy orders with contrasting latitude orders compatible with the strategies of the received strategy orders, and generating a stream of executions for the matched strategy orders at a maximum rate compatible with the strategies of each matched strategy order and contrasting latitude orders; the method being implemented by one or more computer processors of the automated trading system; The method comprises: submitting a first trade order to the algorithmic trading platform, the first trade order having an initial quantity; generating a first strategy order corresponding to the first trading order, the first strategy order being conditional and specifying the side and the first strategy; issuing the first strategy order to the strategy matching venue; canceling at least a portion of the first trading order in the algorithmic trading platform in response to receiving a confirmation message from the strategy matching venue for the first strategy order; determining a current unfilled amount for the first trade order after cancellation by the algorithmic trading platform; determining a maximum amount available for the first strategy order for strategy matching based on the current unfilled amount; sending a definite response to the strategy matching venue indicating a definite amount, the definite amount being less than or equal to the maximum amount; receiving a matching detection condition message from the strategy matching venue; receiving, from the strategy matching venue, a plurality of strategy implementation messages for the first strategy order after receiving the matching detection condition message, each strategy implementation message indicating a respective fill amount; receiving a matching break condition message from the strategy matching venue; determining a current unfilled amount of the first trading order relative to a fill amount indicated by the algorithmic trading platform and a fill amount indicated by the strategy matching platform after receiving the matching break condition message; If the unfilled amount of the trade order is zero, the trade order is completed.

32. 32. The method of claim 31 , further comprising, in response to a non-zero current unfilled amount determined after receiving the matching break message, reissuing the first strategy order to the algorithmic trading platform for an amount less than or equal to the current unfilled amount.

33. detecting a confirmation failure condition when a matching detection condition message is not received from the strategy matching venue for the first strategy order within a predetermined timeout period after issuing the transmission of the confirmation response; 32. The method of claim 31, further comprising: in response to a firming failure, reissuing the canceled portion of the first trade order to the algorithmic trading platform.

34. 32. The method of claim 31, further comprising applying the algorithm constraint to a strategy mapping rule to select the first strategy from the predetermined set of strategies.

35. the step of sending the definite response includes generating a second strategy order linked to the first strategy order, the second strategy order having content specifying the definite amount; 32. The method of claim 31, further comprising: issuing the second strategy order to the strategy matching venue.

36. 32. The method of claim 31, wherein the maximum amount is the number of potential shares associated with the trade order after the trade order is canceled by the management system.

37. 32. The method of claim 31 , wherein the matching detection condition message indicates a maximum fill amount, the method further comprising reissuing the first trade order to the algorithmic processing system in an amount equal to the remaining amount of unfilled share, assuming the strategy matching venues execute trades totaling the maximum fill amount.

38. A system for processing trade orders placed with a trading network, the trade orders specifying a tradable item, a side, a total quantity, and having associated algorithmic constraints, the trading network further comprising a strategy matching venue operable to fill strategy matching orders, each strategy being a member of a predetermined set of strategies, each strategy of the predetermined set of strategies having a base rate or range of base rates, the strategy matching venue matching received strategy orders with contrast rate orders compatible with the strategies of the received strategy orders. and generating a stream of executions for the matched strategy orders at a maximum rate compatible with the strategy of each matched strategy order and a contrasting latency order, the trading network further comprising an algorithmic trading platform that operates to receive a trading order specifying each side, quantity, and associated algorithmic constraints, to fulfill the received trading order by generating a plurality of discrete smaller sub-orders in accordance with the algorithmic constraints, and to issue the sub-orders to point-in-time trading venues for execution, the system comprising: a memory having computer instructions stored thereon; at least one processor coupled to said memory for executing said computer instructions; The computer instructions include: code for submitting a first trade order to the algorithmic trading platform, the first trade order having an initial quantity; code for generating a first strategy order corresponding to the first trading order, the first strategy order being conditional and specifying the side and the first strategy; code for issuing the first strategy order to the strategy matching venue; code for canceling at least a portion of the first trading order at the algorithmic trading platform in response to receiving a confirmation message from the strategy matching venue for the first strategy order; code for determining a current unfilled amount for the first trade order after cancellation in the algorithmic trading platform; code for determining a maximum amount available for the first strategy order for strategy matching based on the current unfilled amount; code for sending a definite response to the strategy matching venue indicating a definite amount, the definite amount being less than or equal to a maximum amount; code for receiving a match detection condition message from the strategy matching venue; code for receiving, after receiving the matching detection condition message, a plurality of strategy execution messages for the first strategy order from the strategy matching venue, each strategy execution message indicating a respective fill amount; code for receiving a matching break status message from a strategy matching venue; After receiving a match break status message, the fill amount indicated by the algorithmic trading platform and the and code for determining a current unfilled amount of the first transaction order relative to a previously filled amount; If the unfilled amount of the trade order is zero, the trade order is completed.

39. The computer instructions include:

39. The system of claim 38, further comprising code for, in response to a non-zero current unfilled amount determined after receiving the matching break message, reissuing the first strategy order to the algorithmic trading platform for an amount less than or equal to the current unfilled amount.

40. The computer instructions include:

39. The system of claim 38, further comprising code for detecting a confirmation failure condition if a matching detection condition message is not received from the strategy matching venue for the first strategy order within a predetermined timeout period after issuing the transmission of the confirmation response.

41. 39. The system of claim 38, wherein the computer instructions further comprise code for applying the algorithm constraint to a strategy mapping rule to select the first strategy from the predetermined set of strategies.

42. 39. The system of claim 38, wherein the code for sending a definite response comprises code for generating a second strategy order linked to the first strategy order and having content specifying the definite amount, and issuing the second strategy order to the strategy matching venue.

43. 39. The system of claim 38, wherein the maximum amount is the number of potential shares associated with the trade order after the trade order is canceled by the management system.

44. 39. The system of claim 38, wherein the matching detection condition message indicates a maximum fill amount, and the computer instructions further comprise code for reissuing the first trade order to the algorithmic processing system in an amount equal to the remaining amount of unfilled shares, assuming that the strategy matching venues execute trades totaling the maximum fill amount.

45. 1. A system for processing a trade of a tradeable item, the system comprising: Algorithmic trading engines and Strategy matching engine, a rate optimization engine in communication with the algorithmic trading engine and the strategy matching engine; The algorithmic trading engine is configured as follows: receiving a trade order for the tradable item, the trade order specifying a side, a total quantity, and having associated algorithmic constraints; (i) over time, generating sub-orders specifying a respective sub-order quantity in accordance with the algorithmically constrained sub-orders from the trading order; (ii) submitting each of the sub-orders to a point-in-time (PIT) trading venue; (iii) receiving fulfillment messages from the PIT trading venue, each PIT fulfillment message corresponding to a respective sub-order and indicating a fill quantity for each of the sub-orders; The algorithmic trading engine may be further configured as follows: suspending and resuming generation of the sub-orders in response to messages from the rate optimization engine; the strategy matching engine receives a plurality of strategy orders from respective sources, each strategy having a respective side, quantity, and strategy, each strategy being a member of a predetermined set of strategies, each strategy of the predetermined set of strategies having a base rate or a range of base rates; matching a tradeable received strategy order with a contrast strategy order that is tradeable and has a strategy that is compatible with the strategy of the received strategy order; Upon forming a match for each strategy order, sending a match detection condition message to a source of each strategy order; generating a stream of executions for each pair of matched strategy orders at a maximum rate compatible with the strategy specified for each matched order while both strategy orders in each match remain tradable; breaking each matching for each pair of matching strategy orders in response to any order becoming non-tradable; in response to each matching interruption, sending a matching termination condition to at least one source of the matching strategy orders in the pair of matching strategy orders for the interrupted matching; The rate optimization engine is configured as follows: applying the algorithmic constraints for a first trade order received in the algorithmic trading to a set of strategy mapping rules to select a first strategy from the predetermined set of strategies; generating a first strategy order corresponding to the trading order, the first strategy order having a quantity equal to or less than the total quantity of the first trading order for the side of the first trading order, and having the first strategy; issuing the first strategy order to the strategy matching engine; receiving a matching detection condition message for the first strategy order from a strategy matching engine; In response to receiving the match detection condition message, sending a signal to the algorithmic trading engine to stop generating sub-orders for the trading order; receiving a plurality of strategy implementation messages for the first strategy order from the strategy matching venue, each strategy implementation message indicating a respective fill amount for the first strategy order; notifying the algorithmic trading engine of the fill amount of each received strategy execution message; receiving a matching termination condition message for the first strategy order from the strategy matching engine; in response to receiving the matching termination condition message for the first strategy order, sending a signal to the algorithmic trading engine to resume generating sub-orders for the first trading order; The system wherein the first trade order is completed when the sum of (i) the fill amount of a sub-order execution message received by the algorithmic trading engine from a PIT trading venue and (ii) the fill amount specified in a received strategy execution message equals the total amount of the first trade order.

46. 1. A system for processing trades of tradeable items, comprising: The system comprises: A transaction management engine; Strategy matching engine, a route optimization engine in communication with the trade management engine and the strategy matching engine; The transaction management engine is configured as follows: submitting a trade order for the tradable item to an algorithmic trading platform, the trade order specifying a side, a total quantity, and having associated algorithmic constraints; canceling and reissuing the trade order to the algorithmic trading platform in response to a message from the rate optimization engine; The strategy matching engine is configured as follows: receiving a plurality of strategy orders from each source, each strategy having a respective side, quantity, and strategy, each strategy being a member of a predetermined set of strategies, each strategy of each said set having a base rate or a range of base rates; matching a tradeable received strategy order with a contrast latitude order that is tradeable and compatible with the strategy of the received strategy order; issuing a confirmation request for a strategy order with matching conditions; After the strategy orders with matching conditions are successfully determined, when a match is formed for each strategy order, a matching detection condition message is sent to the source of each strategy order; generating a stream of executions for each pair of matched strategy orders at a maximum rate compatible with the strategy specified for each matched order while both strategy orders in each match remain tradable; breaking each match for each pair of matched strategy orders in response to either order becoming non-tradable; in response to the breaking of each match, sending a matching termination condition to at least one source of a matched strategy order in the pair of matched strategy orders for the broken match; The rate optimization engine is configured as follows: applying the algorithmic constraints for the trading order to a set of strategy mapping rules to select a first order from the predetermined set of strategies; generating a strategy order corresponding to the trading order, the strategy order having the side of the first trading order, a quantity less than or equal to the total quantity of the first trading order, and having the first strategy; issuing the strategy order to the strategy matching engine; receiving a confirmation request for the strategy order from the strategy matching engine; signaling the trade management engine to cancel at least a portion of the trade order in the algorithmic trading platform in response to receiving the firming request; determining a current unfilled amount of the trade order after cancellation in the algorithmic trading platform; determining a maximum amount available for the strategy order for strategy matching based on the current unfilled amount; sending a definite response to the strategy matching venue indicating a definite amount, the definite amount being less than or equal to the maximum amount; receiving a matching detection condition message from the strategy matching venue; receiving, from the strategy matching venue, after receiving the matching condition message, a plurality of strategy execution messages for the strategy order, each strategy execution message indicating a respective fill amount; receiving a matching break status message from the strategy matching venue; determining a current unfilled amount of the trading order relative to a fill amount indicated by the trading management engine after receiving the matching break status message; A trade order is completed when the unfilled amount of the trade order is zero.

Images