HK1107168A - Block trading system and method providing price improvement to aggressive orders - Google Patents

Description

Block trading system providing price improvement for aggressive orders

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of part of U.S. patent application No. 10/603,100, filed 24/6/2003, U.S. patent application No. 10/603,100, a continuation of part of U.S. patent application No. 09/870,845, filed 31/2001, U.S. patent application No. 09/870,845, a continuation of part of U.S. patent application No. 09/750,768, filed 29/12/2000, and U.S. patent application No. 09/750,768, a continuation of part of U.S. patent application No. 09/585,049, filed 1/6/2000. Each of the applications listed above is hereby incorporated by reference in its entirety.

Technical Field

The present invention relates to a method of managing information to focus block trading interest on a secret matchbook and to conduct block trading over a computer network such as the internet.

Background

In the open securities market, market mechanics and trading psychology form barriers to the dissemination of useful information and the discovery of prices. The decision by a market participant to expose information about his or her true price limit represents a trade-off between market impact costs that impact price expectations and opportunity costs that delay or make no trade. As used herein, the term "market participant" refers to any individual or company having the ability to trade securities; examples of market participants include private investors, brokerage traders, institutions, hedge funds, and statistical arbitrage and other specialized trading operations that trade on Electronic Communication Networks (ECNs).

By displaying the buyer's true price limit to, for example, one or more potential sellers, the market participant is actually selling an option that each seller is free to choose to execute; as long as this option is open, a lower boundary may be set for the market participant's expectation of becoming a fair trade price. Even if one of the sellers originally had a lower price expectation, this expectation could be changed immediately when the buyer's price limit is known, the only remaining problem being whether the fair price should be higher. Indeed, by disclosing a high price that indicates that the buyer is eager to acquire the stock, information that is also worth the seller's attention may be reflected.

Brokerage traders deal with this problem by carefully managing the expectations of parties on behalf of trading parties before finding a fair price, and then proposing a fair price that can satisfy both parties. Today, such agent orders are increasingly being transmitted electronically. In order to avoid the above-mentioned influence on the price expectation, orders regarded as "uncertain" are not displayed on the public market. Brokers may receive match-uncertain orders on behalf of buyers and sellers and personally find a place to inevitably select a fair price somewhere between the limits of the two orders in order to conduct a match transaction. When dealing with such conditions, it is often necessary to decide on its own. For example, if a buyer enters a block buy order of $30.00 at 10 am, and the market has since fallen to the current best bid of $29.80, there is little possibility at this price to automatically match a block sell order of $29.99, since it now appears to be somewhat more expensive than the current market; if the market price is going to rise above this level, the buyer's limit is interpreted as an order to stop buying. However, it is possible to accept a block sell order of $29.82 that also matches the buyer's much higher limit, while a block sell order of $29.85 would prompt the broker to call the buyer.

This human arbitration can result in excessive pricing, both in view of commission payments, and in view of information being leaked to individuals who are affiliated with aggressive trading companies like the hedge fund. This has led large organizations to have a drive to find alternative markets in which they can publish their orders themselves without the traditional brokers having the free intervention.

Electronic markets such as NASDAQ or Electronic Communication Networks (ECN) are not well equipped to handle the price discovery problem of bulk transactions. At its simplest, the electronic marketplace simply displays the buyer's and seller's transactional interests to their customers, and then enables those customers to achieve such buying and selling interests. To avoid affecting the price expectations of market participants, users of electronic markets often enter relatively small nominal tickets for negative prices. And patiently wait for others to execute them, or take a somewhat aggressive stance and execute an order that others have published on the other side of the board.

Some tools are available to "cut" larger orders into a large number of small pieces that can work in the same way, but their activity inevitably reveals the existence of larger orders to those familiar with statistical analysis techniques. Such traders can develop and optimize trading strategies that deliberately detect large secret orders when they are working, and generate benefits by predicting the market impact those orders are likely to cause. The simplest such strategy is to advance the location of the larger order and rely on its long presence to push the price in a profitable direction. Such parasitic strategies eventually exacerbate the naturally induced price movement of the large order in the first place by trading in the same manner as the large order. The final result is quite different from that produced by the publication of a large order on the New York securities exchange: in the latter case, the floor traders "share" the auction orders together, or go directly ahead, intercepting the flow that can attract them. Within the NYSE trading hall, as well as in the electronic market, the terms "penny-jumping" and "front-running" have begun to be used to describe this type of parasitic strategy.

Some ECNs propose more complex order types in an attempt to alleviate the forward movement problem. Some orders (e.g., discretionary orders) try to mask the true price limit by only displaying one price, but retaining priority for execution to the higher secret price limit. These measures suffer from simple counting strategies, such as spraying small orders at different price levels, seeing when the strategy of having orders executed at an undisplayed price level is violated. Other complex order types use a minimum amount condition in combination with a hidden discretionary price to avoid detection by spraying of small orders. Since no price is displayed, there is no "price exposure" in the traditional sense. Then, a block trader of opposite interest can discover the limits of the first order, and indeed have the credit responsibility for doing so, simply by repeatedly entering and canceling orders that are always at a poorer price level, before the order matches the limit of the standing order. Thus, a trader who enters a large hidden order on the ECN to buy at $30.00 should indeed expect to trade at $30.00, even if the seller on the other hand would like to accept any price down to $29.90, although the price is expected to be constant prior to trading.

As a result, electronic books such as supermutage have difficulty attracting relatively large orders at attractive price levels, since most participants quickly learn that it may be more profitable to hide and take prices at which others would like to show or display small amounts at a time. This has led to market evolution where average trading volume has always dropped to about 500 shares, while total trading volume and average institutional order volume have increased.

In such circumstances, there is a pressing need for an electronic trading system that rewards traders who are willing to secretly express their true price aggression with the benefit of price improvement when the opposing party is similarly aggressive. In such bulk trading solutions, the best strategy for aggressive traders should be to enter orders with their aggressive prices, while passive traders naturally get the best service by entering negatively priced orders.

However, addressing such a need cannot come at the expense of the major perceived advantages of electronic trading systems on the traditional market, which is the ability to conduct transactions on-the-fly without human arbitration or pre-trade information leakage.

In short, the challenge is to prevent an order that can be electronically executed at an aggressive limit price from actually being executed at such aggressive price when the contra is in fact willing to also be aggressive.

In order to tilt the scale towards the party in favor of entering an aggressive order without the perceived advantages of electronic speed execution and without the intervention of third party parties, it is necessary to identify value items that can enhance the negotiation position of the party willing to express an aggressive price. One such value item is information. Related application No. 10/603,100, filed 24/6/2003; related application No. 09/870,845 filed on 31/5/2001; related application No. 09/750,768 filed on 29/12/2000; and related application No. 09/585,049 filed on 6/1/2000 (hereby incorporated by reference in its entirety) show how a party willing to privately disclose certificate Trading Interest information to a computer system may obtain the right to receive certificate Trading Interest information from other parties interested in Trading with them. This opens the possibility of reversing the arrows of the information flow when the trader enters an aggressive pricing order in the trading system: instead of showing an aggressive price to the third party, the aggressive price helps the trader attract information from the third party with a more negative deal.

Disclosure of Invention

The system of the present invention overcomes the limitations of known automated trading systems by allowing Market participants to enter aggressive pricing orders into an electronic matching book without disclosing such defined prices to opposing parties or becoming a sacrificial to freely detect the strategy of such defined prices and accepting immediate enforcement when a matching order is found, if the definition of both orders allows, to set the price close to a published reference price, such as a National Market (National Market) intermediate price. The preferred embodiment enables market participants to: (1) entering the hidden order into an electronic matching book of the system without disclosing to the public the attributes and prices of the order; (2) accepting immediate execution of matching contra orders in the book by price time priority at prices close to the national market midpoint price (or other reference price) if the matching order permits; (3) having the system issue an "ACTIVE SYMBOL" indicator to entice other participants to enter orders into this security; (4) receiving a "CONTRA PRESENT" notification when orders are priced aggressively at least as much as the national market midpoint (or other reference Price) and when a second market participant enters a negative CONTRA order into a Block Price Range (Block Price Range) displayed by the system; and (5) if priced at least aggressively as the national market intermediate price (or other reference price), at any time, or if priced more negatively than the intermediate price, the order price is increased after a delay of (say, 5 seconds) so as not to apply a policy that aims to detect a truly qualified price for a long-lived order by sequentially negating and replacing the contra-order on increasing aggressively prices.

The preferred embodiment comprises a method of conducting a block transaction in the form of an alternative to a transaction on a public market, such as a financial instrument, the method comprising the steps of: electronically calculating or receiving a reference price for a small number of alternatives, such as an average of best trader bids to buy and sell the alternatives; electronically storing the reference price; electronically receiving information from a first participant over a network, the information including a block order to buy and sell the replacement; and electronically storing information from the first participant in the electronic matching book. If the order matches other orders previously entered into an electronic matching book arranged by price time priority, the method comprises conducting transactions within the price and quantity attributes of the matching order with a price as close as possible to the reference price and within the allowable range of both orders, and reporting the conducted transactions to the user and to the clearing and regulatory entity. If the orders do not match, pricing the first order more negatively than the reference price, and there is a resident CONTRA order from the second market participant priced more aggressively than the reference price (but not aggressively enough to match the first participant order), the method comprising electronically sending a CONTRA PRESENT notification to the second market participant notifying them that a negative order exists; removing the CONTRA PRESENT notification whenever the second participant order is cancelled or modified to a price more negative than the reference price; continuing to recalculate the reference price and re-price orders from the first participant and the second participant selected to "pin" their orders to the reference price; and executing a pin order for an order with a fixed price and reporting the transaction made to the user and to the clearing and regulatory entity when a change in the reference price makes such execution possible within the scope of two orders.

Advantageously, the transaction may be conducted in a manner that allows the trader who entered the most aggressive order to improve the price, as determined in comparison to the reference price. For example, if a first participant enters an order to buy 3 cents above the reference price and a second participant enters an order to sell 2 cents below the reference price, then trading on the reference price itself gives most of the price improvement to an order with 3-cents aggressiveness. If the buy order is 3 cents higher than the reference price, but the sell order is set to 1 cents higher than the reference price, then a trade is made on the reference price plus 1 cents; in this case, only aggressive orders receive price improvements. If the buy order is set at the reference price and the sell order is set at 1 cents above the reference price, no transaction may be made, but the buyer receives a CONTRA PRESENT notification. Since publishing this information prior to the transaction allows the first participant to withdraw, the second participant who is actually eager for the transaction is left free. Such a trader is most likely to achieve his or her trading goals by entering an order with aggressive definition. On the other hand, if such a second participant is in fact willing to wait for an opportunity to trade at a better price, the CONTRA PRESENT notification plays a constructive role by inviting the first participant to consider a more aggressive price. In both cases, the aggressive trader is a beneficiary of the information contained in the CONTRA PRESENT notification, as opposed to an electronic market where aggressive traders leak information to others before trading, often resulting in negative market impact and low fill rates. Due to this reversal of information flow, the CONTRA PRESENT notification incentivizes traders to express their true trading preferences, resulting in greater liquidity and more efficient price discovery.

An alternative embodiment comprises the additional steps of: electronically calculating a Bulk Price Range (BPR); electronically storing the BPR on a computer readable medium; electronically transmitting data including the BPR and the reference price information over a communication network such as the internet; and displaying the data to a plurality of users through a graphical user interface. An alternative embodiment is preferred to maintain a fixed BPR for up to a certain time interval, e.g. 60 seconds, except that the reference price is suddenly changed due to an event outside the system, the reference price itself being continuously updated. In this alternative embodiment, in addition to the steps described above, the system of the present invention electronically notifies the user that there is active interest in trading alternatives in the meeting system when the first participant enters an order that does not match any contra order currently in the system, but is at least aggressively priced as BPR, i.e., if it is a buy order that is equal to or higher than Block Bid, or a sell order that is equal to or lower than Block Offer, where Block Bid and Block Offer form the lower and upper bounds, respectively, of BPR. In this alternative embodiment, the notification of the presence of the contra is only sent if the contra's order is priced at least as aggressively as the BPR, and is removed if it is subsequently found that one of the two orders causing the contra to give a condition is priced more negatively than the BPR due to a change in the reference price at which one or both of the orders may be pinned, or due to a change in the BPR itself.

Another alternative embodiment functions as described in one of the two embodiments above, but additionally requires that the first participant who has entered an order that is negative with respect to the reference price must wait a minimum amount of time, such as 5 seconds, for notification before allowing the order to be replaced with a more aggressive price. In this alternative embodiment, the second participant, who may have been notified of the presence of a passive contra in the system, may then choose to cancel or re-price the order in order to execute the first participant's return.

A schematic diagram of a preferred computer system embodiment of the present invention is given in fig. 1.

The system preferably includes a transaction facilitation system 100. The transaction facilitation system 100 is connected to the participants through a communication network 80 such as the internet and a financial information exchange network such as the FIX network 90. The system 100 receives market data from vendors 60 via the vendor network 70. The order is sent to the fulfillment engine 50. When received by the execution engine, the matching order is automatically traded. The preferred embodiment includes a web server subsystem 110 responsible for the connection with each client GUI; a financial information exchange (FIX) server 120 that provides connectivity to backend systems and customer order management systems; and an order manager subsystem 130 responsible for implementing the order management logic of a system such as that described herein. The facilitator module 140 creates information events that are intended to focus interest on the deal and direct the user to the deal. The transaction facilitation system 100 tracks the status of its orders in the transaction database 150. The system determines the price aggression of orders compared to a reference price, such as the national best bid and offer median, calculated by the analytics server 160. In an alternative embodiment, the system also measures price aggression relative to a block price range that is then also calculated by the analytics server 160: the price of the order may be (a) more negative than the BPR, or (b) aggressive, meaning within or more aggressive than the BPR. The fulfillment engine 50 receives orders over the communications network 80 and electronically stores them in a transactional fault-tolerant database (book 51); it reports the results of the execution back to the transaction facilitation system 100 over the same network. In alternative embodiments, the execution engine 50 may be hosted locally as an additional component within the system 100.

The participant enters the order into the system using the graphical user interface 20. When the order is executed, the results are reported to their sponsoring broker 95 or to their own firm's Order Management System (OMS)10 using the FIX protocol for processing.

Preferably, all orders are required to be "block orders," meaning that they amount to a multiple of the block quantity. For example, if the block quantity is 100,000, the GUI only allows orders that are multiples of 100,000 shares. Orders may have a defined or better price or have them pinned to a market guide price such as an intermediate price between the best bid and offer on the national market. All valid block orders are sent directly to the fulfillment engine 50 which stores them in the book 50. In an alternative embodiment, orders of any amount are accepted.

The preferred embodiment processes orders on a first come first serve basis. In an alternative embodiment, to additionally incentivize traders to enter aggressive pricing orders, the system advertises a cumulative period of receiving and queuing orders without regard to matches, plus a trading period where orders are entered into the fulfillment engine 50 on a price time priority basis, where buy orders are entered first, sell orders are entered subsequently, and when a match is detected on order entry, they are fulfilled as described above. For example, the system may announce a 15 minute accumulation period and the execution period occupies the last second of each 15 minute interval. In this embodiment, the system alternates between accumulation periods and trading periods throughout the day, for example, accumulation periods of 8:30:00-8:44: 59; 8:45-8:59: 59; 9:00-9:14:59, and the like.

The GUI 20 allows a trader who is interested in trading a given security in a block to click on the security code as in the box displayed above the main screen, bring up an order entry dialog box and automatically populate the fields of the order entry dialog box according to his or her pre-configured preferences. The trader can edit these fields as needed and enter orders by pressing the button with the "Submit" index.

If the newly entered order matches one or more front book orders (the new order belongs to the same security, is on the contra side, and has a price equal to or higher than the long-term active book order), the execution engine 50 automatically ranks the contra order by price time priority and the price closest to the system's current reference price within the limits of the two orders, trades between the entered order and the long-term active order until either the former or the latter is fully executed, and electronically reports the trade results to an automated validation and trading (ACT) service 40 for a unified market display system and to the sponsoring broker's clearing house 30. A notification of the execution is also sent to the graphical user interface 20 to notify the trader of the trading result. If, on the other hand, there are no matching orders in the book, the new order remains stored in the book as a standing order. In a preferred embodiment, customers may choose to have their orders sponsored by third party brokers, in which case the transaction results are also reported to the sponsoring broker's back office system 95 through FIX. In a preferred embodiment, participants who enter a negative order (as compared to the current reference price) are allowed to increase the price aggression of that order only after a minimum delay (say 5 seconds). In an alternative embodiment, the user may replace the order immediately, but the replacement order is eligible for matching only after a specified minimum delay. In yet another alternative embodiment, all orders are not eligible for matching within the system published accumulation period and are loaded into the execution engine 50 in order of affiliate, price aggression, and time after the accumulation period has elapsed. In yet another alternative embodiment, traders may enter orders and modify prices at any time, and the system operator monitors whether a particular user is engaged in the activity of "ascertaining" resident order definitions (and, if so, canceling their account).

To increase the likelihood of a trade, the order manager 130 of the system is connected to a facilitator module 140 which automatically functions when a newly entered order does not find a match, but is stored in the book 51 as a standing order. Once the buy (sell) order is entered, the facilitator notifies, via a CONTRA PRESENT notification, that a standing valid sell (buy) order priced at or below (at or above) the reference price has entered the CONTRA order. In an alternative embodiment, all standing orders for the contra side of the entered order are eligible to receive such notification.

In an alternative embodiment, only reasonably priced orders become the contributing subject; the reasonable price range for a block transaction (block price range) is calculated and published by the analysis server 160 on the trader's graphical user interface 20, which is updated every 60 seconds. In this alternative embodiment, the facilitator 140 generates information events that encourage others to enter orders in the same security without revealing the price or affiliation of the order.

In this embodiment, there are two possible streams of action when the facilitator 140 is made to function, depending on the status of orders known within the system database 150.

In the first case, when a newly entered order does not find a match, the state of the system is such that there are no reasonably priced contra orders within the system. A message is delivered to all parties subscribing to such securities indicating that there is activity in the code body of the newly entered order (if the code is already in the "active" state, this step is omitted). As shown in fig. 2, the graphical user interface 20 will display the activity code in an orange box 215 above the order entry dialog 205. The system preferably enables a second participant who sees an activity code and is interested in trading a block of such securities to bring up an order entry dialog box by clicking on the code. The system preferably populates all fields of the order entry dialog 205 according to the second participant's pre-configured preferences. The second participant acts with the knowledge that the code is "active". Therefore, he will know that the first order to have the ACTIVE SYMBOL notification issued was previously entered, and that this first order is priced within the BPR. With this information, the second participant can choose to submit a limited buy (sell) order for a block offer (block bid) to ensure that the transaction is proceeding if the first order is contra-lateral and is still open. In a preferred embodiment, once the code becomes active, it remains so for at least 60 seconds (or other predetermined period of time); the open active code notification is reviewed in conjunction with the BPR update and removed only if the notification is unresolved for more than 60 seconds and there are no more reasonably priced orders in this code currently open in the system at the time of the BPR update. In an alternative embodiment, the ACTIVE SYMBOL notification is updated in real time to reflect whether there is a reasonably priced order within the system at that time. In another alternative embodiment, the GUI displays, in addition to the colors, the number of reasonably priced orders currently open within the system.

In the second case, there is a reasonably priced contra order resident in the book 51, but this contra order is not quite aggressive enough to meet the limit price set forth by the newly entered order. In this case, the facilitator module 140 sends a CONTRA PRESENT notification to the resident CONTRA order that is eligible to be priced at least as aggressively as the current reference price. If the CONTRA order does not currently meet this criterion, but meets it at a later time due to a change in the reference price, then a CONTRA PRESENT notification is sent at a later time when the condition is met. Once sent, the CONTRAPRESENT notification remains valid together as long as the order remains reasonably priced. In an alternative embodiment, there is no condition related to the reference price, and any standing contra order meeting a reasonable price condition is eligible to receive a contra notification. As shown in fig. 2, the graphical user interface 20 displays a CONTRA PRESENT notification by highlighting the code in the yellow box 225 above the order entry dialog 205. Thus, the first participant to make the code active will see the existing presence partner. The system preferably enables the first participant to re-price the order at an aggressive price and replace the order in order to execute the second participant's order. In a preferred embodiment, the system automatically proposes an aggressive end of the BPR as a default price to encourage a strategy that leads to a trade; the trader can then click to accept the proposed price limit or modify the order log if necessary. In an alternative embodiment, the system enables the user to configure an aggressive order type to be limited to the better of the BPR or a configurable number of cents (or fractions thereof) from the current national market midpoint price, and then this aggressive order type is the one proposed as the default type in the presence of a CONTRA PRESENT notification. In a preferred embodiment, the user is enabled to enter an order that causes the system to attempt to execute the contra order by clicking on the yellow box bearing the code and then pressing a single button labeled for this purpose. In an alternative embodiment, the graphical user interface 20 allows the trader to select a new price and press a button with the index "Replace". If none of the traders with a standing order improve their price aggression and still have a standing contra order after 30 seconds, then it is up to the second participant to be qualified to learn that a standing contra order exists within the system if the second participant's order is then found to be priced at least as aggressively as the reference price. As described above for the first participant, the system preferably displays this information by means of a yellow box; and the second participant may choose to increase his or her price aggression in order to close the transaction. In another embodiment, the second participant's order is only required to be "reasonably priced" to qualify for receiving a CONTRA PRESENT notification after 30 seconds (or a predetermined period). In both cases, the 30 second delay prevents the second participant from attempting to probe the system to find out if only the other is present for later recall; the resident order has 30 seconds to decide whether to take the return or withdraw. In another alternative embodiment, there is no 30 second delay, and all traders receive the CONTRA PRESENT notification at the same time, but there is a minimum validity time of 5-seconds during which orders may not be cancelled. In another alternative embodiment all users receive the CONTRA PRESENT notification immediately without a minimum validity time condition. In an alternative embodiment, traders may configure the GUI 20 to automatically replace their orders with aggressive prices when a CONTRA PRESENT notification is received. In this last embodiment, if there are multiple orders in the system with automatic re-pricing orders and competing execution of the same contra orders, the system executes the response orders with price time priority: to execute the input contra order, standing orders compete first for price and then, if both orders have the same aggressive price limit, for time of input as priority to going to the first order is entered.

The preferred algorithm for calculating the Block Price Range (BPR) seeks to determine the reasonable price for trading a block order within the next 60 seconds based on the volatility of the stock. In the preferred embodiment, this range is based on the price since the last time the BPR was updated to report the transaction results to the unified market display system, using a symmetric price range around the current intermediate price of the nationwide best bid and offer. This range extends relative to the intermediate price by an amount that has a direct relationship to the price volatility observed since the most recent BPR update.

Abbreviations

Abbreviations	Full scale	Description of the invention
			ACT	Automated validation and transaction service	Allowing real-time comparison of transactions and forwarding of clearing information

		Nasdaq facility to custody trust and clearing company (DTCC)
			API	Application programming interface	Enabling third party developers to create front-end application software that interfaces with the system and allows remote users to access it
BlockLink		System body for enabling a user to facilitate a bulk transaction by sending a transaction invitation to an associated application of a potential counterparty party
			BPR	Bulk price range	It is believed that there is reason to affect the price range of a block transaction
Enum	Enumeration	Terminology used to denote the type of data in an electronic information storage facility, where the possible values taken are all within an enumeration table
			PCM	Faithful capital market	Examples of possible sponsoring brokers for the system entity of the present invention
FIX	Financial information exchange protocol	Protocol for communicating order and transaction information in a financial marketplace
			GUI	Graphic user interface	Front-end application program intended to enable access to the system body of the invention
INT	Integer number of	Generally refers to the type of data in an electronic information storage facility
			IOC	Go to the nearest or cancel	Indicating that if an order cannot be filled immediately, its order attributes should be cancelled
IOI	Interest indication	Message for use in financial markets to indicate interest in purchasing or selling securities
			LBQ	Bulk quantity	Standardized order amounts per code for use in the system body of the present invention to improve the chances of order matching
LQT	Mobility tracker	Nasdaq facility body for related applications referenced herein
			MID	Intermediate price	The same price from the best bid and best offer on the national market

MPID	Market participant ID	4-letter abbreviations for identifying brokerage traders on the Nasdaq market
			NotHeld		Order attributes for brokers to decide on their own to manage orders and to manage rules associated with determining orders, independent of order display
OATS	Order form examination tracking system	System for national security trader to supervise and operate for market
			OMS	Order management system	A computer system that allows the company to track the status of orders, the parts that execute or are working on, etc.,
Peg		indicating that order attributes for a defined price are calculated at a time of chance of matching with reference to a national market
			PegOffset		Order attributes that append cents to pinned prices
Q/A	Quality assurance	Component of software development Process
			Ticket		Messages sent from an order management system to a broker or trading system indicating an intention to trade a certain number of shares through this broker or trading system
TIF	Effective time	Order attributes indicating time intervals during which orders are valid

Drawings

FIG. 1 is a schematic diagram of a preferred computer system embodiment of the present invention;

FIG. 2 depicts a preferred GUI opening an order entry dialog box;

FIGS. 3(a) and 3(b) depict the operation of a preferred system and method involving the interaction of the system with the participants and the electronic systems of the relevant companies;

FIG. 4 illustrates the life cycle of a transaction from a clearing perspective in a preferred embodiment;

FIG. 5 depicts preferred steps that are preferably performed while processing New Ticket (a New Ticket);

FIG. 6 depicts the preferred steps of processing a Cancel Ticket message;

FIG. 7 depicts preferred steps for processing a valid order;

FIG. 8 depicts a preferred monitoring table configuration dialog box;

FIG. 9 depicts the steps of a preferred method of calculating BPR; and

FIG. 10 depicts a preferred GUI identifying monitored securities.

Detailed Description

The following is a detailed description of preferred and alternative embodiments of the invention.

Key features. The following is a preferred list of features of the invention:

1. secret large match. Orders are sent to a matching engine that matches orders with price time priority and reports locked trades for clearing. The matching engine may be hosted remotely.

2. Bulk quantity. All orders are preferably entered in multiples of the block quantity configured per security. By encouraging users to use the same order size, the bulk security amount discourages gambling and mitigates the "buyer reover" problem or error party concern after completion of the fill.

ACTIVE SYMBOL notification. In an alternative embodiment, the system also notifies the user when it is determined that both parties to the stock exchange are interested in the block transaction. This focuses on order entry in time, thereby increasing fill speed.

And 4, CONTRA PRESENT notification. When a nearly matching contra order is entered, the trader with an aggressive pricing order (associated with the reference price) in the system is notified. After 30 seconds, if the second order then meets the price aggression condition, the participant with the second order may also be alerted that a close match exists. The CONTRA PRESENT notification rewards traders who enter an aggressive pricing order with information about the negative counter offer, thereby encouraging traders to express their true price aggressiveness.

5. And connecting with FIX in the background. The preferred embodiment supports a mechanism for communicating FIX executions to the buyer order management system either directly or through the FIX service bureau. This situation supports the closing anonymity of the buyer client with the sponsoring broker.

FIX ticket processing application. Customers can place stocks from their order management system into the system (codes, quantities and parties) and then gradually arrive at the entered quantities using the GUI 20. The OMS may be updated to track individual work orders or, depending on the configuration of the client, only upon fill.

API/GUI access. The system provides an optional trading front end designed with input from the institutional trader that highlights the code for the watch list of securities of interest that have received a CONTRA PRESENT notification. In an alternative embodiment with an ACTIVE SYMBOL notification, this ACTIVE SYMBOL notification is also displayed. The system also exposes an Application Programming Interface (API) that enables licensed third party parties to receive such notifications on behalf of their customers and provide visibility through their own front-end applications. In an alternative embodiment, such notifications and block price ranges may also be obtained via the FIX protocol serving market data.

The present invention includes a preferred architecture that integrates the system with the electronic systems of participants and associated companies, such as the sponsoring brokers or their clearing companies. An overview of this integration is shown in fig. 3(a) and 3 (b). These figures illustrate the flow of causing a transaction between participants C and E as described below. For standing orders already in the system, the new participant can enter a contra order. The system sends out a CONTRA PRESENT notification; the resident order is modified to a higher price aggressiveness level resulting in an executed trade.

The system preferably facilitates the transaction in the above example by:

1. in step 1, the user enters an order into the system, preferably using a graphical user interface 20.

2. The system preferably specifies the record broker in step 2 and verifies the order against any credit line based on the record broker and the customer ID. The order information is stored in a database 150.

3. In step 3, the order manager 130 sends the order to the fulfillment engine 50 and expects an order update message back from the fulfillment engine indicating whether the order was filled on input, stored as a valid defined order, or cancelled if the order is invalid.

4. OM 130 notifies facilitator module 140 of the order item event once it is found that the order is not executed or cancelled in the execution engine.

5. The facilitator module 140 discovers that there is a counterpart with an aggressive price that exists in the system; it immediately sends a CONTRA PRESENT notification to the resident opposite and if it is then found that the new order is aggressive, an event is scheduled to issue this same message to the second participant who placed the new order, after a delay of e.g. 30 seconds.

6. In step 6, the contra-present message is transmitted to the resident order.

7. Step 7 preferably occurs 30 seconds later than the sending of the first peer presence message: if the contra-present condition persists and then aggressively prices a new order as compared to the reference price, a contra present notification is transmitted to the new order.

8. In step 8, resident orders (i.e., sponsoring customers who use the service bureau for their FIX connection to the system) receive a CONTRA PRESENT notification on their GUI 200 and modify the orders to improve price aggression.

9. In step 9, OM 130 sends a modify order request and updates the status of the order in OM database 150.

10. In step 10, OM 130 transmits the modified order request to execution engine 50.

11. In step 11, the enforcement engine 50 determines that the new price aggression is sufficient to lock the transaction, and preferably reports this transaction result to the ACT along with the clearing partner information. In an alternative embodiment, the transaction results are only reported for the market display system, and the clearing information is retained until the closing, so as to delay the time at which the sponsoring broker is notified of the transaction results.

12. Preferably, fulfillment engine 50 reports fulfillment results to order manager 130, and OM 130 updates the status of orders in its database 150 and updates the credits consumed.

13. In step 13, order manager 130 reports the transaction results to web server 110 and FIX server 120.

14. Web server 110 and FIX server 120 forward the execution message to their respective clients.

15. The second customer receives the FIX execution results through the service bureau.

16. In the final step of the trading process, a drop copy (drop copy) of the execution results is sent to the sponsoring broker. In the preferred embodiment, this is done at the time of closing. In an alternative embodiment, this is done immediately and the sponsoring broker is notified directly of all trading activity that the sponsoring broker recommends.

Facility

The system preferably comprises the following facilities or subsystems:

1. a web server 110. The web server subsystem enables clients to access the system through the graphical user interface 200. This interface is preferably the most appropriate interface that can be used to enter orders into the system. All users must download a transaction application (GUI) or develop a GUI that provides satisfactory visibility of the active code and the contra present flag. The web server 110 preferably supports connections to the transaction front-end through published APIs.

FIX server 120. The FIX server enables a user (client) to open a connection and exchange financial information messages according to the FIX protocol. The source code of the FIX server may be obtained from an open source code library. The FIX server is preferably configured to receive Ticket (New, Cancel, Cancel/Replace) and order status request messages. It will push executions including order updates and fills. It preferably supports direct connections to the customer order management system, as well as connections through the service bureau. The FIX server may also be used to communicate an execute message (with a "done" status) to the sponsoring broker for setup after transaction processing. Typically, these messages are sent on the closing of the order, but it is also preferable that the customer request the system to notify their broker of the results of the day's execution when needed.

3. An order manager 130. The order manager processes the orders and subsequent trading messages, passing them to the fulfillment engine for storage and fulfillment. It preferably receives BPR update messages from the analytics server 160 and maintains the price aggression flag on its orders by tracking the time at which orders are priced at least as well as BPR, or orders are priced negatively.

4. A facilitator module 140. As described herein, order manager 130 preferably contains components responsible for facilitating matching in order entry systems by carefully distributing information about orders.

5. An order management database 150. Order manager 130 preferably tracks the status of trades and may fully restore orders in a Structured Query Language (SQL) database. It also contains a reporting module responsible for reporting the transaction results to the clearing company and for generating mandatory reports daily for delivery to the corresponding self-supervision organization (SRO).

6. The analysis server 160. The analysis server 160 receives data feedback informing the server of the market activity status of each code (start, stop, transaction pause), the internal best bid and offer (price, total amount, and time stamp) of all Nasdaq and NYSE listed stocks, and the last sold transaction data from the national market system unified market display system. The server stores this information on a computer readable medium, such as a hard drive, and performs analytical calculations as described above to determine the reference price and the block price range. It is responsible for publishing changes in reference prices, BPR update messages and transaction suspension to subscribers by code.

7. Help desk. The system preferably includes a help desk subsystem that includes a user interface such as a web GUI. The help desk operator may access this interface to add/delete/modify customer company, sponsoring broker or GUI accounts associated with the various traders. The help desk enables the trader to follow the sequence of events after entering a customer order into the system, based on the order ID or by company and code query system, and to give traders who want to invoke the help desk detailed responses to the history of their orders in the system.

8. And (5) managing system operation. The system preferably also includes a system operation console subsystem that enables a system operator to manage the functional implementation of all of the facilities. In addition to the ordinary system operating responsibilities, the system preferably also enables the operator to perform other responsibilities including: keeping secret; examining; managing batch processing of disc closing and opening events; planning the capacity; and the right to manage internal accounts (operators and help desks).

9. A matching engine 50. The matching engine 50 stores the participant's orders in an electronic matching book 51 and deals when the buy and sell orders are entered at overlapping prices, selecting the execution price close to the reference price if the price limits of both orders allow.

Preferred implementations of the above features are described more broadly below.

A FIX server. The preferred embodiment preferably uses the FIX protocol for background integration with the customer order management system 10 and sponsoring brokers as needed. FIG. 4 illustrates the lifecycle of a transaction from a clearing perspective. To use the system, the customer is preferably able to choose between the two models. A first model is the use of tickets to facilitate the management of debts among multiple market destinations. Tickets are surrogates from customer order management systems that help traders monitor how many shares they are trading in each market destination (a market destination is where orders can be executed like current systems). The purpose of the ticket is to ensure that the cumulative number of shares entered at all destinations never exceeds the total number of shares for all orders of the customer as known by the customer order management system 10. When the trader uses the tickets, the tickets input from the OMS appear on the GUI 20, and orders can only be entered against these tickets.

A customer selecting a ticket for use preferably can only enter an order into the system if the order belongs to the same security, is on the same side, and has a value no greater than the previously entered ticket. When the trader chooses to use the ticket, the system preferably updates the background and third party systems by performing the following steps.

1. In step 410, the ticket is entered into the system 100 as a FIX order without a price. The ticket carrying system maps it to the terminal ID of the particular GUI. The trader sees the ticket displayed on his/her GUI.

2. In step 420, the trader enters an order referred to herein as a "sub" order against this ticket. This sub-order belongs to the same security and party as the ticket and the selected amount is the lesser of the default order amount or ticket amount configured by the trader. The system preferably validates the order and passes it to the fulfillment engine 50. In a preferred embodiment, the ordering event is reported to the OMS via a FIX execution message with Order Status New. In an alternative embodiment, the client OMS only receives the execute message when the transaction is complete (see below).

3. When a transaction occurs for this order, the fulfillment engine 50 preferably reports to the ACT regarding the market display system and clearing (step 430). Then, the order manager 130 is notified of the transaction result. In a preferred embodiment, the system then notifies both an API client, such as a GUI, and a FIX client, such as a customer order management system, of the transaction details.

4. In step 450, the system preferably sends a FIX execution message including the customer ID to the executing broker.

5. The system preferably enables the user to initiate the dispensing process (at the user's option, step 440) before the date or end of the transaction.

6. The preferred system performs the following steps (step 460) upon closing the disc.

a. The trade summary file is sent to the sponsoring broker's clearing house. This file contains information about the clearing including the code, the number of shares sold or bought and the MPID of the opposite party.

OATS reports give a summary of order tracking and execution on behalf of the sponsoring broker. The system automatically sends the OATS report to the sponsoring broker for forwarding to the NASD. In an alternative embodiment, the report is sent directly to the NASD. These file transfers are in electronic form and use the File Transfer Protocol (FTP).

In a preferred embodiment, the user is enabled to choose an alternative configuration that does not require the use of a ticket, but rather enables the trader to begin the processing of the order entry step 420. The remaining steps are the same as described above.

In an alternative embodiment, the system 100 is hosted by a sponsoring broker for all customers using the system, and includes a post-transaction processing subsystem that can be readily implemented by one of ordinary skill in the art or that is commercially available through specialized vendors. In this alternative embodiment, there is no need for closing anonymity, and broker performance reports may be sent immediately.

The FIX server 120 preferably supports a variety of networking solutions that provide connectivity to the customer order management system 10. For example, the guest OMS may connect directly to the FIX server, or may communicate with the FIX server 120 through a FIX service bureau that mediates the connection between the FIX server 120 and several clients.

When the ticket is invalid or when the client is configured not to use the ticket, the FIX server 120 rejects the ticket; the ticket rejection message preferably carries an understandable reason for rejection in a text field. If a rejection message is sent because the order quantity is less than the block quantity of such securities (LBQ), it is preferable to give the correct LBQ for the information in the message text in the rejection message. In the preferred embodiment, FIX server 120 preferably supports the following arrival messages: FIX New Order, Cancel/Replace, and OrderStatus Request. If the customer uses the ticket, the outgoing message preferably includes an Order Update (FIX execution message carries the Order-ID of the underlying ticket) associated with the sub-Order of the given ticket. A client that does not use a ticket preferably receives only an execution message (FIX execution message). In an alternative embodiment, a customer not utilizing a ticket receives an Order Update message for each event related to an Order entered through the GUI, including a New Order confirmation message, so that the OMS can track the overall model being run, and the amount that has been executed, event by event.

FIX server 120 preferably supports a web configuration screen that enables an operator to set up and customize new client connections without changing the system software. As described above, the FIX buyer client may preferably be configured only for (a) FIX execution, or (b) to support ticket processing and execution reporting. The FIX sponsorship broker client is preferably configured to receive only the results of the execution. In an alternative embodiment, the FIX connection of the sponsoring broker may be configured to receive an outgoing copy of each message sent to the OMS with the sponsoring client. In addition to the execution message sent each time the Order is executed, the configuration options preferably include the option to send the last FIX execution message when the Order is complete, and the Order Status field set to "complete" to indicate that work on this Order has been completed.

An order manager. Order manager 130 functions as a message processor. In the following paragraphs, the processing of various messages will be described.

The system preferably enables a user to enter a New Ticket message. The New Ticket message is a FIX New Order message with Order Type Market and no price limit. FIX Order with a defined price will be rejected. In an alternative embodiment, this message may be submitted on an Application Programming Interface (API) of the system.

The following steps are preferably performed at the time of processing the New Ticket (see fig. 5) after the Ticket is received in step 510.

● verification. In step 520, the system preferably processes the New Order by first validating the fields in the FIX New Order message. The ticket must contain a valid Client-ID, Trader-ID (mapped to a special GUI), the security and the owner (buy or sell), and be at least as large as the block quantity of this security. Preferably, Cloud9 accepts FIX orders identified as "Market" orders and "Not Held" and rejects tickets containing a defined price. In an alternative embodiment, the restrictions on price and Not helld status are Not mandatory. Preferably, the customer is only allowed to have one ticket per security on each side. If the previous ticket is still approved, a second buy or sell ticket for the same security will be rejected. If the previous ticket has been executed or cancelled, you can enter a second ticket; it will replace the first ticket on the GUI front end. An alternative embodiment employs a front end capable of displaying multiple tickets per security and allows a customer to enter any number of tickets. Other commercial FIX order attributes will not be ignored. The reject ticket is preferably displayed on the GUI with a reasonable code.

●. The system preferably stores valid tickets in database 150. The ticket is then displayed on the client GUI via the web server 110 in step 540, and the ticket is confirmed back to the client OMS via the FIX server 120 in step 530. The following table gives the required fields in the Ticket message in the preferred embodiment.

Field(s)	Description of the invention
		ClientID	Companies entering tickets
ClientTicket ID	Specially adapted for this company
		Trader ID	GUI where tickets will be seen
Quantity	Number of strands
		Side	Buy or sell only
Price	Must be left vacant

Symbol	Is supported within the system
		Type	Must be the market
NotHeldFlag	Must be provided with

The system preferably enables a user to enter a Cancel/Replace packet message. The Cancel/Replace Ticket is preferably submitted as FIX Cancel/Replace Order with the ClientTicketID of the previously opened Ticket and the ClientTicketID of the new Ticket. In an alternative embodiment, this message may be submitted on the API. In the preferred embodiment, upon receiving the Cancel/RepleTicket message, the system performs the following steps.

● verification. The system entity of the present invention preferably rejects the Cancel/ReplaceTicket message if the new quantity minus the quantity already executed (the new "number of licenses") is less than the system block quantity for the code, or if it is less than the total number of shares placed on the execution engine as open orders (open order) (the number of licenses is less than the number of jobs).

●. If the request is accepted, Cloud9 preferably modifies the ticket amount to be applicable to any subsequent singleton and pushes the changes to the client GUI via the web server 110. Changes returned to the client OMS are also preferably confirmed by FIX.

The system preferably enables a user to enter a Cancel Ticket request. The Cancel Ticket message is a FIX Cancel Order message with the ClientTicketID of the previous opening Ticket. In an alternative embodiment, this message may be submitted on the API. The system body of the present invention processes the cancel ticket message as follows (see fig. 6).

● verification. The system preferably verifies the field of the CancelRequest message in step 610 by ensuring that it points to the opening ticket.

●. If there are open orders, then in step 620 the system will first attempt to cancel all open orders associated with the ticket and then dynamically report with a message any executions completed before cancellation 630 (this "elimination" process is ended when all relevant orders are executed or cancelled and the database of the Cloud9 order manager is consistent with the database of the execution engine in any populated state). When any open orders are eliminated, the system will, in step 640, validate the Cancel Ticket with the result indicating the amount cancelled, if any. In step 650, the client GUI is notified of a successful Cancel Ticket request by the web server.

The system preferably enables a user to enter a New Order message. The New Order message is preferably submitted via a GUI or API and contains a request to buy or sell a given number of large hands of a given security at a defined or better price. In a preferred embodiment, the user may also choose to pin the price limit, in which case the order is limited to a less aggressive price between the absolute limit price and the pinned limit price. In an alternative embodiment, the user chooses to suspend entering New Order by FIX, by distinguishing tickets (FIX orders with Execuntr ═ suspended) from New orders (not suspended) using the FIX Execuntr field, or does not choose to use tickets at all and interpret all of their FIX orders as a New Order message. The New Order message is managed most as follows.

And (6) verifying. The system preferably verifies that the order is a multiple of the bulk quantity for the supported instrument. In alternative embodiments, orders may be for any number. Another step in the preferred order validation process is to verify that the order contains a price field. In an alternative embodiment, if the user selects a pin price, in which case the pin order may float unrestrictedly, then the request is discarded. The type of pinning supported in the preferred embodiment is a pinning of the NBBO medium price, or no pinning at all. Alternative embodiments support additional pinning attributes, as known to those of ordinary skill in the art. The system preferably also verifies whether the party to the order is a buy or a sell. Alternative embodiments also support short-term sell orders. The parameter PegOffest determines the score (or a fraction thereof) relative to the pin value (NBBO medium price) that should price the order. If the order is not pinned, the PegOffest attribute is preferably ignored. The system preferably reports rejected orders to the GUI client, along with understandable error codes. If the customer uses ticket processing, the validation step preferably also verifies that the order does not exceed the associated ticket amount and is of the same party as the ticket. If there is a credit line between the customer entering the order and the sponsoring broker, as part of the verification process, the system preferably verifies that the order does not violate said credit line; the credit verification process will be described in more detail below. In a preferred embodiment, if the system has received an order within the last 5 seconds (or other predetermined period), which is of the same security and party as the current order, and which is more negative in price than the current order and more negative than the reference price at that time, then the order is rejected. In an alternative embodiment, such an aggressive pick order is accepted, but marked as unexecutable until the 5-second delay elapses. In another alternative embodiment, all orders are not executable until the accumulation period has elapsed, but are then submitted to the execution engine 50 in order of the party, price and time entered. In yet another alternative embodiment, there is no such condition, and orders can be entered at any price at any time and can be executed immediately, but when a particular user is found to have a pattern that checks various price levels in an attempt to ascertain the price limits of resident orders, the help desk operator is notified, and the help desk operator calls the customer, notifying them that such action is not permitted. The help desk operator in this embodiment is given certain criteria so that if the action is not corrected, they can terminate the customer's right to conduct a transaction on the system.

In a preferred embodiment, the IOC order is rejected as invalid. In an alternative embodiment, the owner of a standing CONTRA order that accepts an IOC order but is eligible to see a CONTRA PRESENT notification can see the CONTRA placing an IOC order that cannot be executed (in the preferred GUI, the code changes from orange to yellow for a while and then changes to orange again). In yet another alternative embodiment, the IOC order is accepted, but no CONTRA PRESENT notification is sent.

An order attribute. The system of the preferred embodiment expects to find the required fields in the New Order message as given in the table below.

Field(s)	Note
		ClientID	Company for entering orders
Trader ID	GUI for entering orders
		ClientOrderID	Specially adapted for this company
Quantity	Number of strands
		Price	If pinned, it is optional. If the pinned value exceeds the limit, the pinned order with the limit acts to define the order.
Side	Buy or sell only
		Symbol	In the first-class market
Time-in-Force(TIF)	FIF is the absolute time or day. All orders are invalidated at the end of the trade day.
		Peg	MID, NONE. At the pin value or better.
PegOffset	The number of signed dollars to be added to the pin price.

And (6) processing. The system preferably processes the valid order (see fig. 7) by the following steps.

● upon verification (step 710), the valid order is passed to the fulfillment engine in step 720. The response will indicate whether the order was rejected or accepted and placed in the book as an open order or in a pending execution state. The status from the execution engine is reported to the GUI via the web server.

● if the customer uses FIX Ticket, the system preferably reports the order status as accepted or rejected as returned by FIX (step 730); the execution pending status will be reported as open status in FIX (the locked execution message will follow later). The FIX order status update message carries the ID of the associated ticket.

● if the fulfillment engine indicates that the order is open, the system will initiate the process 740 by a facilitator that helps improve the likelihood of a trade.

The preferred embodiment determines if there is an aggressive contra order in the system. If the contra is on and priced at least as aggressively as the current reference price for the code, the spoken order is an aggressive contra order. The user with the aggressive CONTRA order receives the CONTRA PRESENT notification immediately. Users with contra orders that are not currently eligible for aggressiveness are eligible to receive such notifications as long as they are subsequently aggressively eligible for a change in reference price. If it is then found to be aggressive, an event is preferably scheduled at the order entry time plus 30 seconds (or other predetermined period) to send a CONTRAPRESENT notification to the newly entered order. This preferably occurs regardless of whether the resident contra order is eligible to receive notifications. Thus, a user who enters a negative order into the system may find such an order to exist for which the user would like to enter aggressive orders in 30 second or longer intervals. In an alternative embodiment, only the deferred CONTRA PRESENT notification is sent if the resident counterparty is found to qualify to receive such notification first.

In an alternative embodiment, the system also determines, per order entry, whether the price of the new order is at least as aggressive as the most recently published price of the Block Price Range (BPR), and if so, marks the order as "reasonably priced". If the order is identified as "reasonably priced" and the code is not already in the "ACTIVE" state, the system issues an ACTIVE SYMBOL notification to all users inviting them to place an order in such a security. In an alternative embodiment, a block price range is also calculated, the CONTRA PRESENT notification is sent only if the price of the new order is reasonably priced, and removed if it is later determined that each order is no longer reasonably priced due to changes in order price and BPR.

● in step 750, the system waits for additional orders to arrive. The contra order is processed as above starting with the verification step 710. Contra orders with equal or better prices are preferably executed as close as possible to the then popular reference price.

The system preferably enables a user to enter a Cancel Order message. Cancel Order is a GUI/API message with ClientOrderID corresponding to the previous New/Replaced Order. In an alternative embodiment, the cancel order request may also be received via FIX.

And (6) verifying. If the order ID is invalid or points to an order that is unknown within Cloud9 that becomes open, the cancel order request is denied.

And (6) processing. The system 100 preferably processes the Cancel Order request as follows.

● Cloud9 OM 130 passes the active cancel order request to the execution engine 50.

● the execution engine 50 responds with the cancelled stock. The cancellation response may be performed after execution. For filled (fill) or expired orders, the cancel request is denied.

● upon receiving a successful cancellation response from the execution engine 50,

pushing order status update messages to the GUI client 20 and the analysis server 160.

If the customer uses FIX Ticket, status updates are also reported by FIX.

Release the credit assigned to this order.

O if a "CONTRA PRESENT" notification has been issued in connection with this order, the notification is removed in case there is no longer a counterpart.

Attention is paid to: in an alternative embodiment with ACTIVE SYMBOL notification, it is preferable that the cancellation order not remove this notification. The user may continue to enter orders on both sides in response to the notification, resulting in a trading opportunity. In another alternative embodiment, the ACTIVE SYMBOL state is directly linked to the presence of reasonably priced orders in the system.

The system also enables the user to enter a cancel/replace order request to modify a previously entered order. In the preferred embodiment, Cancel/Replace Order is a GUI/API message that points to (ClientOrderID) previously valid New/Replaced Order. In an alternative embodiment, this message may also be entered via FIX, with the same configuration options as described above for the New Order message.

And (6) verifying. ClientOrderID should point to a valid order. If an order is directed that is known to be cancelled, due or executed, or if price aggression is improved for a previously negative order before a minimum delay (say, 5 seconds) has elapsed, the system preferably denies the cancel/replace request; alternative embodiments of this functionality are described above for NewOrder messages. The system preferably supports pre-transaction credit verification. Thus, if the amount of the order increases due to the cancel/replace request, the system first verifies to the user's account that the new amount does not exceed the credit line. A replacement order request that fails credit verification is rejected, rendered invalid, and the reason for credit is specified by a reason code.

Cancel/Replace Order treatment. Preferably, Cloud9 OM 130 processes the cancel/replace order message by passing it to the execution engine. The fulfillment engine 50 responds with an order status that includes the fulfilled stock, the remaining open stocks, and the average price.

● trade messages. The status update message is pushed to the GUI client through the web server 110.

● status updates are also reported by FIX if the customer uses FIX Ticket.

● if the cancel/replace modifies the amount of an order, the credits assigned to this order are cancelled and replaced to reflect the new order.

A transaction message. The execution engine 50 reports the transaction result to the order manager 130 through a transaction message. Each transaction message from the execution engine reports a locked transaction involving exactly two orders.

The fulfillment engine 50 matches the book of contra orders to the individual orders (one-to-many match). There may be multiple respective transactions after the match check, each of which will be processed independently.

Since the transaction is a single transaction, both legs of the transaction should be reported as a unit.

The preferred embodiment of the system contemplates finding the following fields of the transaction message.

	Description of the invention	Type (B)
			TradeID	ID relating to this transaction	Character string
NewOrder ID	One in one-to-many matching "	Character string
			ResidentOrder ID	Contra order	Character string
Quantity	Number of strands	INT
			NewAvgPrice	Average stock price of all executions of an order	FLOAT
NewFilled	Number of executed stocks	INT
			ResidenAvgPrice	Average stock price of all executions of an order	FLOAT
ResidenFilled	Number of executed stocks	INT
			Price	Is reported to ACT	FLOAT
ACTTrade ID	Is reported to ACT	Character string
			TimeStamp	Is reported to ACT	HHMMSSCC
BidTimeStamp	Recent quote received by the transferor (whether to cause a price change)	HHMMSSCC
			OfferTimeStamp	Recent quote received by the originator (whether or not to cause a price change)	HHMMS SCC

The transaction message is processed. The system 100 preferably processes the transaction message from the execution engine 50 by the following steps.

● for a client that uses a Ticket or requests a FIX for execution, two executions are reported to the relevant GUI client by FIX.

●, the credits are updated to reflect the actual amount of credits consumed based on the transaction price.

● if the trader uses the ticket and the amount remaining on the ticket is less than the bulk amount of the code, the amount remaining on the ticket is voided.

● sends a bulk market display system message to the web server for delivery to the GUI monitoring such securities. The bulk market display system message preferably contains the following fields.

	Description of the invention	Type (B)
			TimeStamp	Reporting by an execution engine	HHMMS SCC
Quantity	Number of strands	INT
			Price		FLOAT
TotalQuantity	Total number of such securities trades since opening of the disc	INT

The system preferably enables a trader to cancel all orders previously entered into the system in an emergency with a single request. CancelAllClientOrder s is a message from a web server requesting to cancel all orders entered through a given GUI. In an alternative embodiment, this message may also be transmitted via FIX. Since the execution engine 50 does not know the customer ID, Cloud9 OM will process the Cancel-all messages by canceling each Order associated with this customer in the open state separately, processing them as individual Cancel Order requests.

In embodiments that contain block price ranges, the order manager 130 subscribes to the analytics server 160 for BPR update messages that exist for the securities for which orders were opened, and updates the equitable pricing conditions upon receipt of the BPR update messages. If the reasonable price status of an order changes, the order manager 130 re-evaluates all orders for this security for the presence of contra-present conditions and updates the contra-present notification as described above. If this results in a change in the contra-present status on the order, the system preferably sends a CONTRASTENT notification update to the affected UGI client. In embodiments with ACTIVE SYMBOL notifications, the system also updates these notifications according to BPR update messages. If the code is in an Active state, in this state for at least 60 seconds (or other predetermined period), and there are no more orders in the BPR, the code is set to a "Not firm" state, and the web server sends an Active SYMBOL notification update message with SymbolStatus Not Active. In an alternative embodiment, the active code state is updated on any BPR update message, and may be set to an inactive state even if the code has stabilized in less than 60 seconds. In yet another alternative embodiment, the activity status is updated each time a national market best bid and offer price is changed and each order entry or cancellation to ensure that the activity status always reflects the presence of a live, reasonably priced executable order in the system at that time.

Execution engine. The execution engine 50 in the preferred embodiment is hosted in the same facility as the Cloud9 system 100, and the two systems communicate over an intranet. In an alternative embodiment, the execution engine 50 is a component within the Cloud9 system 100. In both embodiments, the function of the execution engine 50 is as follows. The fulfillment engine 50 receives an "anonymous" order, meaning that the order is stripped of the buyer customer ID and instead identified with an internal order ID and a sponsoring broker ID. As we describe in more detail below, the fulfillment engine 50 processes newly entered orders by checking to see if there is a resident description matching the entered order and trading with price time prioritized resident orders.

The execution engine 50 in the preferred embodiment is a log that restores the true state of any Cloud9 transactions in the event of a failure.

The preferred embodiment of the fulfillment engine 50 supports both defined orders and orders that pin the NBBO medium price.

In alternative embodiments, other order types known to those of ordinary skill in the art are also supported. For example, the alternative fulfillment engine may support automatically increasing its price aggressiveness when placing other orders into the system, in price time prioritization, to keep the price at the top position discretionary for orders. Such orders are then preferably re-priced one jump point (tick) better than the best other orders of the same code and affiliate, as long as the absolute limit price of the discretionary price is not violated. In another example of an alternative embodiment, the system enables traders to enter orders priced at a later time based on volume weighted average format (VWAP) over a forward time interval, such as VWAP from trade time to take-up, or VWAP over a particular time interval, such as a half hour interval. For example, such an order may be priced to purchase up to two cents higher than VWAP in the 11:00-12:00 future time interval. In this embodiment. ACTIVE SYMBOL notifications for future priced orders show the time interval for pricing orders and take care of all orders that must be priced in response to such notifications in relation to the same future average price. Thus, the VWAP time interval effectively forms part of the definition of the surrogate being traded. Similarly, alternative embodiments enable a user to enter an order in a pair of securities, or a package containing multiple securities. The ACTIVE SYMBOL notification describes the composition of a trading cell and expects the trader to respond with a buy or sell order for the same trading cell. In these alternative embodiments, the reference price and the bulk price range must be generalized to a VWAP order or package. For a VWAP order, the reference price is the VWAP itself, while for a pair and a package, the reference price is an average of the prices of investment instruments in the pair and package, weighted by the dollar value of each item based on its reference price.

All orders are either defined designations or orders priced in relation to the reference price (pinned orders). If the pinned order also has a defined price, then it is better to consider pricing the order when the defined value or the pinned value is more negative. In embodiments with future pricing orders like VWAP orders, it is preferable not to allow absolute price limits. Once the transaction is locked, it is clear what the price will become in the future. In an alternative embodiment with a future priced VWAP order, the user may announce a stop price on the VWAP order. If this price level is broken before the pricing period has elapsed, the period ends prematurely, locking the trade on the corresponding portion of the stock only at the VWAP up to this point. For example, if the market price breaks $21.15 after 45 minutes have elapsed for the next hour, then an order that stopped at $21.15 (e.g., the current price may be $21.01) to buy 100,000 shares in the future VWAP for the next hour will close. Since 3/4 time has elapsed, 75,000 shares of VWAP over the 45 minute interval will lock the transaction. Such stop prices protect the buyer from the risk of rapid price fluctuations within the pricing interval and allow the seller to enjoy a higher market price, entering the remaining stock count.

The fulfillment engine 50 preferably allows the pin order and the limit order to interact. The order is priced pinned when a match check event occurs, and then the pinned order is treated the same as the defined order when the defined price or the pinned price is more negative. In a preferred embodiment, the pinned value is the NBBO medium price as the reference price plus a PegOffset amount that may be positive or negative.

Enabling the user in the preferred embodiment to pin for protection of defined orders to ensure that their orders do not trade at prices that are suddenly seemingly very aggressive compared to NBBO if the market changes rapidly. The GUI 20 suggests this way of using pin bits by representing features as "price protection" and providing the option of "do not trade if the median price exceeds < n > cents relative to NBBO".

Since there are both pinned and defined orders in the system, matching can be triggered not only by order entry, but also as a result of changes in the NBBO price that match the price of the pinned order to the defined price of the opposite order.

Thus, in a preferred embodiment of the invention, the match may be triggered by the entry of a new order, or by a change in the price of the NBBO that matches a pinned order with other orders. The system preferably implements the following process in order to identify such matches.

The execution engine 50 preferably includes means for receiving all bid update messages from the data provider 60 and tracking current best bid and best offer delivery, using information caching techniques known in the art. It is also preferable to enable the components of the enforcement engine 50 to subscribe to price update messages for a given security, and thereafter receive messages whenever the best bid or best offer for a given security changes.

The fulfillment engine 50 preferably maintains a list of one party's presence of one or more defined orders and on the other party's presence of one or more codes that pin the orders, subscribing to NBBO price change messages for all securities in this list. For purposes of this section, pinned orders with a defined price are considered pinned orders if their price is taken as a pinned value and pinned orders with a defined price are considered defined orders if they are priced as input (i.e., the pinned value is more negative than the defined price) when received by the execution engine 50. For each code in this list, the fulfillment engine 50 preferably sets a buyer threshold defined as the value of the pinned order being equal to the value of the reference price that best defines the contra order and/or a seller threshold defined similarly to the pinned buy order so as to intersect the defined buy order. Once each NBBO price changes, the system preferably calculates a new reference price and determines whether this price breaks the buyer threshold or the seller threshold. If the buyer threshold is broken, the system proceeds to conduct a transaction between pinning the buy order and the defined contra order in price time priority as if the buy order was just entered into the system, whereas the sell order is similarly processed when the buyer threshold is broken.

If multiple pinned orders are all eligible to match the sell order, they are preferably ranked by price time priority according to the effective price at that time, so if two orders differing in absolute qualifying price are pinned to the NBBO intermediate price, they are not tied to the qualifying price because they have the same effective value, and their ranking is determined by the time entered, with the oldest order at the highest priority.

The execution engine 50 preferably observes transaction suspension on the primary market as follows. At the time of the security break, all existing and new orders will be rejected. The execution engine 60 infers the status of the stock exchange from the data vendor 60. If the data vendor 60 is unable to provide the service or the corresponding communication network 70 fails, the enforcement engines do not process any transactions, but simply wait until the critical service is reestablished.

The market data fed back in the preferred embodiment contains market suspension information, as well as level 1 and last sales data, for use by the analysis server 160.

If the new order triggers a match, the execution engine preferably immediately reports the execution pending status to Cloud9 OM 130, as well as the expected total match amount. As described below, this report is information that is only available to the facilitator 140, and no guarantee that the transaction will be due.

The transaction is preferably processed as a single transaction using software programming methods known in the art to avoid the risk of the system reporting one party to the transaction and not the other party to the transaction in the event of a computer failure. Processing the transaction preferably involves the following steps.

1. If necessary, the transaction results are reported to the regulatory organization and the order status in the database is updated. In the preferred embodiment, the transaction results are reported to the Nasdaq ACT system. The matching engine will immediately report to the ACT for data publishing (ticker system reporting) and for clearing purposes.

2. When a transaction is successfully locked for clearing (ACT confirmed transaction report and specified ACT report ID), the enforcement engine 50 preferably sends a corporate transaction report message to the order manager 130. Transactions involving the pinned order are preferably reported with a time stamp for the last bid and a time stamp for the last offer used to calculate the NBBO medium price, and a time stamp for the processing execution results.

The execution engine 50 processes incoming messages as follows:

and (5) carrying out New Order treatment. New Order is a message from OM 130. It is best treated as follows.

● identify matching orders, if any, and confirm the order entry with the status to the order manager 130.

● if the order is not filled, but results in a defined order on one side and a pinned order on the other side, the registration is updated in the security for the NBB price.

● process any of the transactions described above.

Cancel Order. Cancel Order is a request from Cloud9 OM to Cancel an open Order. It is best treated as follows.

● checks whether the Cancel Order request carries a valid Order ID that points to an Order in the book 51.

● the cancel order request message is rejected if the order has already been traded.

● if the order has not been traded:

marking order status as "cancelled" in the execution engine database (book 51).

Report successful cancellation status to order manager 130.

In a preferred embodiment, orders can be modified or cancelled at any time, unless the price aggression of negative orders is increased as described above. In an alternative embodiment, the order is required to have a minimum validity time of 10 seconds in order to give the other participants reasonable time to react to an event triggered by the facilitator 140, such as an activity code or a peer presence notification.

The system preferably also enables the order manager 130 to cancel all orders associated with a given sponsoring broker, or all orders together. Fulfillment engine 50 processes such aggregated request to cancel orders by first identifying all affected orders and then processing the request to cancel orders by order entry time.

The fulfillment engine 50 preferably verifies the connection to the order manager 130 using a 30 second heartbeat. In the event of a connection failure, the system preferably cancels all orders.

A network server. The system preferably includes an application programming interface that enables the client GUI 20 to connect to the web server 110 over a communications network, such as the internet. The web server 110 allows the customer front-end application to access Cloud9 transaction services like viewing of BPR updates or entering orders into the system.

If a failure to connect to the client is detected, Cloud9 preferably attempts to cancel all client orders with the execution Engine 50. In an alternative embodiment, the system allows the client to select a configuration where failure of the connection does not cause the open order to be cancelled; selecting the client of this alternative embodiment then has to invoke the help desk to cancel the order in an emergency.

The web server 110 passes the transaction activity messages (order, cancel/replace, cancel) to the order manager and passes the response and unsolicited messages back to the client. It also has a client GUI configuration such as the position and size of the window on the screen and a list of securities that the trader wants to monitor. These examples do not constitute an exhaustive list, but are for illustrative purposes only. Other configuration parameters may be stored to support GUI display options, as will be readily understood by those of ordinary skill in the art.

In a preferred embodiment, the GUI enables the trader to view credit warnings generated by the system when the number of available credits drops below the dollar number typically required to conduct a block trade. In an alternative embodiment, no credit warning is displayed, and the user may simply find that there is insufficient credit once the order entry request is questioned.

In an alternative embodiment of the present invention, the GUI 20 enables a trader to access a dialog box that facilitates managing the monitoring tables of a security. The purpose of the monitoring table is to restrict the flow of information from the system to codes of interest to the trader. In this embodiment, the system preferably also enables the trader to see if there are any more people currently monitoring a given code with an open GUI (which is interesting because it increases the likelihood of trading). In an alternative embodiment, the GUI 20 enables the user to see the number of traders monitoring a security. The GUI 20 will register only in the monitored securities for BPR update messages and for receipt of activity codes and contra-party presence messages. In a preferred embodiment, the API allows the GUI to register for BPR/Active/Contras Present messages in any security and separately register for quote update messages in a separate list of securities. Preferably, the GUI 20 displays NBBO prices for only one security at a time, i.e., the one that opens the order entry dialog box as shown in fig. 2. In an alternative embodiment, the GUI subscribes to NBBO updates in all monitored securities and displays these prices next to the code in the rollout list.

To manage the watch list, the user is preferably able to add individual codes, or all codes sorted by a known group of securities, such as an industrial group or a gate class. The system preferably also enables users to submit their own sets of securities in the form of Excel files and assemble these into the system, at which point they can simply be added to a list of sets of securities from which the trader can choose to populate his or her watch list.

A preferred monitoring table configuration dialog box is depicted in fig. 8. The user can add code or arrays of code. The change is in a pending state before the user saves the change. The user may also revert to a previously saved monitoring table, or load a set of securities from an Excel spreadsheet that may be derived, for example, from their OMS or notepad.

The monitoring table is preferably managed by the client and always on the server.

In embodiments with monitoring code notifications, web server 110 preferably keeps track of which codes are being "monitored" by two or more GUIs. If the code is added to the trader monitoring table such that the number of monitoring clients reaches two, then the web server 110 will broadcast a message to all GUIs subscribing to the activity code message to indicate that the code is monitored. If the number of monitoring GUIs drops to one, the network server will broadcast a message to the GUI subscribing to the activity code update to indicate that this code is no longer being monitored. In an alternative embodiment, a message is sent each time a user joins or removes monitoring of the code and the updated number of parties that presented the code, time stamp, and monitored the code.

The GUI 20 preferably shows all codes in the trader monitoring table and ACTIVE or PRESENT each other by using orange for ACTIVE codes, yellow for CONTRA PRESENT notifications, and color-coded rectangles highlighting them at the top of the GUI. In an alternative embodiment, a message indicating that the monitoring code becomes active or there is a counterpart is displayed through a temporary pop-up screen, similar to the instant messenger application. In another alternative embodiment, these pop-up messages are visible until action is taken by clicking on the generate order entry dialog and entering the order in response to the message, or by clicking on the "close" or "minimize" button to close the pop-up screen or to shrink it to a stick underneath the screen.

The trader GUI 20 in the preferred embodiment has the option of showing or not showing the code in the "monitor" state on its monitoring table (i.e., at least one other trader is monitoring this code). If they choose to view these codes, they are represented in a third color with no other two colors to wake up, when they are not "active" or there is no other party present, since the trader's attention is not immediately required. In the preferred embodiment, the GUI 20 represents the monitoring code with a grey square next to the active and present counterpart squares.

The web server 110 preferably exposes APIs to remote clients for accessing system services. The API preferably enables the user to open a session through basic authentication (username, password) before using any transaction service. In an alternative embodiment, the client authenticates itself with a certificate. The user credentials exchange is preferably accomplished through an SSL session that exchanges encryption keys using a web server public key. Once the user is authenticated, the session is mapped to the user identity.

The web server API preferably exposes the following functionality.

● Get vector List: each company may selectively arrange the securities in groups of categories or other securities. The grouping of securities may be configured per customer company. The API returns a list of securities associated with the client company and group name.

● Get Security List: the system has a list of configured securities. This function returns that list. Each element in the list is a code, a company name, and a gate class.

● Set & Get tractor Defaults: the system enables the client to store default parameters. The following list is not exhaustive, but contains some trader default parameters of particular interest; other parameters will be apparent to those of ordinary skill in the art.

Default mounted amount. The order entry dialog box will fill the quantity field with the minimum number (block quantity) of this code, or by default with the trader's total ticket amount if the trader uses a ticket.

Default Price. The order entry dialog box will populate the price field with a defined price selected by one of the following rules: the aggressive end of NBBO, the negative end of NBBO, the medium valence of NBBO; and for embodiments comprising a BPR, the aggressive end of the BPR, the negative end of the BPR, or an intermediate valence of the BPR.

Default TIF. The order entry dialog box will fill the validity time field with this number of seconds.

Default Watch List Management (Security, Sector). All monitoring tables are managed by the front end and are always on the server.

Default Peg and offset. The order entry dialog will default to selecting or not selecting the pin option, and if selected, add the dollar value as the pin offset for buy orders, or subtract the dollar value from the pin intermediate price for sell orders.

O. Ticketed Orders Only. This option determines whether the trader wants to check the order against the amount reserved by the ticket. If this option is not selected, the trader can enter an order even if there is no corresponding ticket.

Set & Get Sector Watch List: a list of securities, including a gate or other group, is saved and retrieved.

Set & Get Symbol Watch List: a list of securities that are in a given monitoring table is saved and retrieved.

●Set&Get GUI Defaults：

Packet Management Grid: the option to launch an application with a window displaying a list of tickets is opened or hidden.

Packet Management Grid definition: font, fieldorder, colsize, coltype, heads, and field ═ colmappings.

Color Changes (Yes, No): the GUI preferably allows the user to select this option, highlighting any fields of the order in the order entry dialog box, when the order has been submitted to the system and from there this field has been edited. When the field has been edited, the user may press the "Replace" key and send the new value to the system via a Cancel/Replace order message. Highlighting fields that have been edited helps the user manage the order.

● Get Heart Interval. The number of seconds of the periodic heartbeat that determines whether the connection between the GUI 20 and the web server 110 can function. The system preferably imposes a lower limit on this parameter to avoid overloading the network server 110 with connection management responsibilities. In an alternative embodiment, the parameters can only be set on the server and not exposed through the API.

● Get Tickets: a user ticket is acquired. The user can only have one ticket per code/party during the transaction day. If the ticket is cancelled, the amount drops to an unexecuted amount. The same code and a new ticket for the same party replace the items in the list.

● Get Orders: a list of all orders is obtained.

● Get Order Status. Order details of ClientOrderID are returned.

● Submit New Order: new orders are queued into the system. Followed by asynchronous invocation of the onorderapdate or OnOrderReject event.

● Replace Order: this function queues the substitute order request. Once returned, the caller assumes that the order state is under "Pending Replace". Followed by asynchronous invocation of the onorderapdate or OnOrderReject event. The replacement order details are the same as the new order details + OrigClientID field. The amount is the total amount including the amount that has been performed.

● Cancel Order: this function queues the cancel order request. Once returned, the caller assumes that the order state is "Pending Cancel". Followed by asynchronous invocation of an onorderrepdate or onorderdercanced event.

● Execute Trade. This function requests that this transaction be reported to the sponsoring broker in order to set up the allocation process. This may be done automatically at the end of the trading day.

● Get tracks for (ClientOrderID, Symbol or ALL) Request/response torrieve track details. This request preferably has three forms. The trading results are obtained for an order, for all orders of securities, or for all trades of this GUI client.

The API events, i.e., messages generated by the system and pushed to the GUI 20 through the API, are as follows.

● OnTicketUpdate: this event is promoted for new, replaced and cancelled ticket events.

● OnOrderUpdate: for order status changes, the event is promoted. This includes order management responses to requests on or through other channels.

● OnOrderReject: the event is promoted in response to a new/replacement order request entered within this session.

● OnCancelReject: the event is promoted when the cancel request is denied.

● promote the OnTrade event when there is a trade in one of the trader orders entered through this API or another channel.

The preferred embodiment of the web server 110 also provides an interface to subscribe to market data for each security and stores the data on a computer readable medium such as a hard disk. The fields include: (NBBObid, ask Tape Timestamp), (BPR Low and High), Block Tape (Last and totalvolme), Active Symbol, contrast Present, Security State (open, closed, half, etc.), and timestamp. The functions shown in the preferred embodiment of this interface are:

● Subscribe Request/Response: this function preferably adds the list of securities provided in the request message to the client's subscription list. The request returns a snapshot of the current data for that item for the requested field. Subsequent changes to the monitor field will raise an update event (OnPdate) with a change.

● Unsbscribe Request/Response: the subscription request is removed.

● OnUpdate Event: the subscribers to the notification field change within the subscription item.

● Start Active Symbol Feed Request/Response: a list of all codes with the active code flag set is returned. After the call, all state changes in the active code flag change will result in an OnActiveSymChange (Symbol, On/Off).

● Stop Active Symbol Feed Request/Response: the event notification described above is terminated.

● OnActiveSymChange event notifies the subscriber of an active code flag change.

Research data storage. The system preferably stores information about the system activity on a computer readable medium such as a hard disk or magnetic tape. This stored data enables operators and researchers to monitor various measures of system activity, and in particular, to evaluate how different measures of transaction activity for a code correlate with filling speed when a user enters an order. This information plays an important role in directing the use of the system to workflow through the marketing and sales media and access to the trader workstation, resulting in greater success. For example, if the fill rate after entering an order for an unmonitored security is extremely low or zero, traders may be advised to focus their trading emphasis on the system of securities being monitored by other traders. The system may also preferably be reconfigured to modify the rules of when to issue flags to increase the fill speed of the system. For example, if it is determined that the fill rate is substantially higher when three or more traders monitor more than two securities, then the system may be reconfigured to issue monitoring code messages only when the total number of GUI users is three or more, rather than two or more. The above examples are for illustration only and do not provide an exhaustive list. Other optimizations based on modifications of the parameters given above will be apparent to those of ordinary skill in the art.

The transaction activity metrics may be used on a help desk and output to a persistent data repository at the end of each day for offline analysis with the purpose of discovering associations between possible system configuration settings and higher fill speeds.

The metrics of interest are:

● order Activity (enter, BPR aggressive Change; Cancel/expire)

● perform

● Ticket

● number of traders who can see the code activity flag (on the watch list, as a code, or as part of a gate class)

● the number of traders (subscribers) who can see the BPR update

● can see the number of traders (subscribers) who are offering to update

The following data tables (A-D) are stored in the form of standard Comma Separated (CSV).

Table a. ticket table

	Description of the invention	Type (B)
			Timestamp	To one hundredthSecond of	HHMMSSCC
Symbol		char[5]
			Quantity	Multiples of bulk quantities	INT
Side	Buy and sell	Enum

Table b. order form table

	Description of the invention	Type (B)
			Timestamp	To hundredth of a second	HHMMSSCC
Symbol		char[5]
			Quantity	Multiples of bulk quantities	INT
Side	Buy and sell	Enum
			BPR	Yes/no	Boolean
Status	Open, deny, cancel, expire, execute	Enum

Expired and filled

Table c transaction table

	Description of the invention	Type (B)
			Timestamp	To hundredth of a second	HHMMSSCC
Symbol		char[5]
			Quantity	Multiples of bulk quantities	INT
Side	Buy and sell	Enum

Watch D. monitor watch

	Description of the invention	Type (B)
			Timestamp	To hundredth of a second	HHMMSSCC
Symbol		char[5]
			SymbolActiveWatchers	Number of clients able to see code activity flag (marked on their watch list)	INT
BPRWatchers	Number of clients monitoring code BPR updates	INT
			QuoteWatchers	Number of clients monitoring quote update of code	INT

Analysis server

The analysis server 160 in the preferred embodiment tracks the nationally best bid and offer prices by listening to the vendor offer feedback 60 and updating the NBBO price when the offer that is the best price is cancelled or increased by a new offer with a better price. The current NBBO price is preferably stored on a computer readable medium such as a hard disk or magnetic tape. In addition to the NBBO price, the analytics server 160 also calculates a block bid and a block offer based on the last quote and transaction data.

The main function of the analysis server is to generate the following messages:

● NBBO price variations, and

● for embodiments that contain a block price range, the BPR update message.

The analysis server 160 stores the last sales data for all supported tickets and all changes to internal bid or offer prices throughout the day. The data that needs to be stored for analysis is described in tables E and F.

TABLE E inside market price update

	Description of the invention	Type (B)
			Timestamp	To hundredth of a second	HHMMSSCC
Symbol	First-level market code for securities	char[5]
			ChangeType	New delivery, new issue, both	Enum
BidPrice	Jumping in units of 1 cent	FLOAT.2
			OfferPrice	Jumping in units of 1 cent	FLOAT.2
SecurityState	Trading states of securities (open, close, pause, etc.)	Enum

TABLE F Final sales

	Description of the invention	Type (B)
			Timestamp	To hundredth of a second	HHMMSSCC
Symbol	First-level market code for securities	char[5]
			Quantity	Amount of transaction	INT
Price	To a few tenths of cents	FLOAT.2

The analysis server 160 transmits a quote update message to all connected clients whenever the best bid price or best offer price for the inside market changes. The update message carries a new bid price or new offer price and a timestamp associated with the occurrence or removal of an offer to change this bid or offer.

The analysis server 160 also preferably updates the BPR every 60 seconds and, in embodiments with a BPR, sends a BPR update message to the order manager 130 to determine the price aggression of its order and to the web server 110 for broadcast to the GUI client 20.

Embodiments that include bulk price range calculations include a replaceable module responsible for calculating the BPR. The BPR may be calculated using methods known to those of ordinary skill in the art, such as by taking a block bid equal to the national best bid price minus 5 cents and taking a block bid equal to the national best bid price plus 5 cents. In another embodiment, the cents to be added (subtracted) from the NBBO price are set in proportion to the historical volatility of the stock, so that for very unstable codes like technology stocks, the change may be more than 5 cents, while for more stable stocks like blue financing, the change may be a little less.

An example of a more accurate algorithm for calculating BPR considers the highest and lowest prices H and L traded in the past 60 seconds, respectively, and the current NBBO medium price M, and calculates a block bid and a block issue bid (fig. 9) by:

● step 910. For a given security, prices H, L and M are determined as defined above.

● step 920. The last sales data in the time stamp returned to the last BPR update is examined to find the transaction that is priced furthest away from the current NNBO intermediate price. Let X denote the absolute price difference between this trade price and the current NBBO medium price. Thus, X is the larger of H-M and M-L.

● step 930. Let Z ═ Y + (maxblockaksread/2-Y) ((1 +1/(1+ exp (-BETA X)), where Y is a parameter set for each security that sets the lower limit of the price difference between the block bid and the block issue, maxblockaksread is the upper limit of the price difference, and BETA is a parameter that can be set to, for example, 10.0.

● step 940. A block bid equal to M + Z and a block bid equal to M-Z are calculated.

● step 950. A BPR Update message is sent to order manager 130 and network server 110.

These examples are for illustration only: other means of calculating a block price range can be readily envisioned by one of ordinary skill in the art.

Credit management. The system preferably enables the sponsoring broker to set a credit line against their customer's account. In a preferred embodiment, the credit check accounts for the total value of the buy stock plus sell stock based on a total dollar limit. The credit for the order is validated based on the greater of the top of the BPR and the defined price of the order, and the credit is adjusted based on the actual amount of credit consumed when the order is fully executed, expired, or cancelled (or partially executed).

● giving the broker a web account to manage credit; they can view the credit level currently consumed by the client, but only within the following interval: less than 25%; 25 to 50 percent; 50-75%; greater than 75%.

● brokers must be able to increase the current day credits available soon; alternatively, they may increase or decrease the amount of credit that gets refreshed at the beginning of each trading day. Brokers may also suspend credits; this may affect the day and days later. If the current day's credit is suspended, the system will cancel all open orders.

● the broker may later undo the credit suspension for the customer. The pause has a permanent effect and lasts until the next day. The credits are refreshed upon closing.

● the broker can set the credit warning threshold to a percentage of the total (default 75%); additionally, the system will generate an alert whenever the available credit falls below a system configuration dollar value MinCredit (e.g., $2 million) that is too low to use the bulk system. The credit alert is delivered to the help desk operator and pushed to the customer GUI.

Help-seeking desktop. The system preferably provides a help desk interface for use by an operator managing calls from customers. This user interface may be a web browser interface, with access being guaranteed by public key encryption and certificate-based authentication, as well as a username and password pair. The interface preferably enables the user to view detailed information regarding the age of the order. The user may pop up a list of orders with a given code and client ID to locate the order that the customer is asking. The help desk interface enables its user to click on an order of interest and view the following messages in chronological order.

● ticket, if applicable.

● order entry request.

● order entry response: reject (with reason code); pending execution; expiration; and (4) opening.

●.

● compares the CONTRA PRESENT notification sent by the order.

● modify order requests and responses (accept, reject).

● cancel order requests and responses (accept, reject).

● expires.

In addition, the help desk operator can see the price in NBBO, the timestamp of the last quote seen at the tray-delivering and tray-issuing parties, BPR price and timestamp, respectively, for each significant event (enter, cancel, execute) in the life of the order. This can be used to answer questions: such as why the code changed or not changed to an active state when the order was entered, etc.

In an alternative embodiment, the help desk operator cannot view the code or the owner of any order, thereby reducing the privacy risks associated with traders who are aware of the trading interest of the institution's customers. In this embodiment, the help desk operator identifies the caller's order by popping up a list of orders associated with the trader, using the time entered and the amount of each order, and the ClientOrderID also visible on the trader GUI 20. The help desk operator is working on the trader, identifying which order he or she is looking for, and then proceeds as described above by clicking on the order to view the corresponding activity track.

In a preferred embodiment, the help desk also enables its operator to select clients from the drop-out list and view their configuration in relation to the transaction logic. The following list gives the more important user configurations and user statistics of the help desk operator; this list is not exhaustive and other lists may be readily understood by one of ordinary skill in the art.

● credit line and consumed credit.

● trader activity: number of orders, number of shares traded, number of dollars traded.

● trader list; one is selected to view and edit the transaction options.

● monitor table management (add/remove code, add/remove industrial group).

● show/not show active code bars.

● show/do not show a lead-out list of tickets.

● default ticket attributes.

The preferred embodiment also enables brokers to access the home page using the same authentication and privacy model as used for help desk operators. The broker uses this web page for credit management. To maintain privacy of the customer, the interface preferably restricts information from being displayed to the broker in a manner that does not expose details of the customer's transaction. In this embodiment, the broker can only view the amount of credit consumed by the customer as a percentage of the total credit line; for example, this may be limited to four intervals: less than 25%; 25 to 50 percent; 50-75%; and greater than 75%. It also enables the sponsoring broker to modify the client's credit by the following functions.

Plus the day credit.

Plus the day's credit and also increase the amount of refreshments for the next few days.

Reducing the amount of refreshment several days later.

Suspend credit.

Withdraw credit suspension.

In an alternative embodiment, the outcome of the trade is immediately reported to the sponsoring broker, and the sponsoring broker is able to view the executed trade, as well as the exact credits consumed. In another alternative embodiment, the sponsoring broker may also view pre-trade activities.

System configuration interface. The system preferably enables an operator to modify the configuration and add/remove clients or sponsoring brokers during redundant system maintenance.

The system configuration interface enables a system operator to join a customer and set desired configuration attributes to enable a user to conduct a transaction. The new client company must select the sponsoring broker from a list of available brokers. The sponsoring broker is preferably unique to all traders within the same company. In an alternative embodiment, the same company may use several sponsoring brokers, and the GUI 20 lets traders select a sponsoring broker as an order entry. The new company may optionally establish a FIX connection directly with FIX server 120, through a FIX service bureau, or through the sponsoring broker 95. In the latter case, the sponsoring broker forwards FIX messages from the client to the FIX server 120 on its own behalf. Depending on their workflow requirements, companies can choose two modes of FIX connection: the FIX channel may be set to receive only the execution result, or to receive the execution result and the order update message. They may be arranged to enter tickets and to check the GUI input order against the amount dispensed by the ticket, or to work without tickets. When a client company is added to the system, the help desk operator will call the broker, set a credit line for the customer's account, and agree to the client-ID for a take-up report. The new user is preferably required to configure the GUI/API access to enable transactions to be conducted on the system. In an alternative embodiment, user input is also supported through the FIX interface, and the user is not required to access using the GUI 20 or API.

The system configuration interface preferably also enables the system operator to add the sponsoring broker to the list of supported brokers. In an alternative embodiment, the system is operated by a single sponsoring broker and is not accessible through third party broker relationships. In configuring the sponsoring broker, the operator will create a user account for the sponsoring broker in order to manage the credit of their client accounts as described above. Broker contact information, such as telephone numbers, faxes, and emails, must be entered and stored in the system database 150. The rescue desktop operator will use this data to contact the broker for credit issues. To complete the process of setting up a new sponsoring broker, the following steps are preferably performed.

● the broker must establish a FIX connection in order to receive all outgoing copies of the execution results. If the broker is also acting as a service bureau for the client OMS and sends tickets on behalf of the client, this same connection is also used as a FIX connection with the client.

●, a closing file is created that contains the details of each transaction, including the identity of the buyer customer for each transaction.

● optionally, a closing file is created with the buyer's transaction details that is transferred to the broker clearing house at the time of closing.

Further enabling the operator to add or remove securities from a list of securities supported for trading. The securities are preferably associated with parameter values specific to the present invention, such as block quantities and parameters used to calculate block price ranges in embodiments involving block price range calculations by the analysis server 160. An example of the use of a set of required fields for a security is given in the table below.

	Description of the invention	Type (B)
			Security	Security name (blob of choice)	Character string
Symbol	In the first-class market	char[2，3，4，5]
			Primary market	NYSE，Nasdaq	INT
LargeBlockQuantity	The order must be a multiple of this quantity	INT

MinBlockSpread	Minimum score between bulk delivery and bulk distribution	INT
			MaxBlockSpread	Maximum score between bulk delivery and bulk distribution	INT
Beta	Renormalizing bulk price differential extrusion parameters	FLOAT

System operation. The system in the preferred embodiment preferably includes an operator console for providing centralized management of servers, network hardware, and transactions. Operating software to support the required functionality is commercially available in a form that provides at least the following features.

● real-time display of all server statistics

● summary of problems

● problem solving feedback

● remote management/monitoring

● Intelligent Notification System (Warning)

● Warning display, confirmation and comments

● audible alarm

● Log record

● help online

The operator console allows the system operator to perform the following remote actions:

● System Start

● System restart

● System shutdown

● system component restart

● System component shutdown

● System component startup

● System backup

● database backup

● start/stop within a day

● reset when closing the disk

● executing a closing batch process

The system additionally enables the operator to generate daily usage reports at the time of the closing and to extract the necessary information for billing, research, clearing and OATS reports from these reports.

The operator also preferably uses the system operation tool to create a clearing summary that contains a list of trades with broker IDs for both parties to the trade. The trade summaries all trades related to the sponsoring broker and for which the clearing house contains at least the sponsoring party for the given broker.

The system preferably also generates a billing report containing a list of all executions involving the sponsoring broker for transmission to the broker. Execution should be one-to-one matched to the current day's execution report. The closing report additionally contains the client ID masked in the current report. If both legs of the trade are recommended by the same broker, there will be two execution reports in the summary file.

The preferred embodiment saves two copies of the data described below to the removable media for archiving and analysis. The log of events includes a date-time stamp accurate to milliseconds, if possible.

● System and application Log: the applications and systems on each machine are marked and saved. The log is preferably reset before opening the disc.

● configuration review: details of the opening and closing review of the company (NT registration, application configuration, etc.) are recorded.

● ACT message: there is a separate log containing details of all ACT messages. This log is preferably reset before opening the disc.

● order and trade: the order and the transaction table are copied to the removable storage at the time of closing. A separate log of details about order state transitions is maintained. The logs and tables are preferably reset prior to opening the disk.

Operation activities are as follows: operational activities that affect system behavior are logged. The log record is time stamped and includes the identity of the operator. This log is preferably reset before opening the disc.

All system activity logs and daily reports are preferably moved to persistent storage before the end of each transaction day. The system activity log contains information sufficient to reconstruct the trading logic and pricing for each order and trading event, including the time stamps needed to resolve pricing disputes.

The system is preferably configured to automatically restore service in the event of an unexpected failure using a process based on the following considerations.

● loss of the GUI. The GUI 20 is the channel required for the Cloud9 service. If the web server 110 detects that the connection to the client is lost, in the preferred embodiment, all orders are automatically cancelled and the system generates an alert to the help desk operator with the order cancelled, with the telephone number of any trader. The GUI 20 preferably displays the order status as "cancel pending". Upon reconnection, the order status is updated to "Cancel". The trader can pop up a list of orders cancelled as a result of a connection failure and reactivate those orders; the system treats them as new orders and processes them accordingly. In an alternative embodiment, the user is enabled to select a configuration that does not cancel their order in the event of loss of connection to the GUI; in this embodiment, when the connection cannot be restored, the user will invoke the help desk to cancel the order.

● loss of FIX. A FIX connection loss preferably does not cause order cancellation because FIX is not the channel that manages executable orders. Once FIX connection is lost, the operator must be warned. Upon reconnection, the FIX client will resynchronize with the server as required by the FIX protocol. In an alternative embodiment, FIX may be used to enter executable orders into the system, and the system supports a configuration that enables users to request that their orders be automatically cancelled once FIX connectivity is lost.

● analyze the server. If the analytics server 160 is out of service, the system in the preferred embodiment will continue to function, but will not receive the benefits of the functions normally implemented by the facilitator, such as a new ACTIVESYMBOL message (for embodiments with ACTIVE SYMBOL notifications) or a CONTRA PRESENT message. The GUI 20 will not be able to receive quote update and BPR update messages. If the analysis server 160 cannot be quickly restored, the system operator places the order, placing the system in an offline state that rejects any further order entry, but does not cancel the existing order. These solutions are described as examples of how a trading system like in the present invention solves the reliability problem, but other solutions can be easily understood by those of ordinary skill in the art. For example, one alternative is to treat the analytics server 160 as a critical service and automatically shut down the system and cancel all orders once the service is lost.

● web server, order manager, and facilitator. These services are closely related to the vital functions of the transaction system. Thus, in the preferred embodiment, the failure of these services is considered fatal; when a loss of connection is detected, the operator will either attempt to cancel all orders in the execution engine, or automatically cancel those orders. Upon detecting a failure of any of these services, the system automatically goes to an offline state.

A system management console running continuously on an independent system constantly monitors the integrity of the system. If the integrity of the system becomes uncertain at any time of the trade day, the system will automatically switch to an offline mode. At this point, all orders are cancelled. All further orders are rejected before the system returns to a fully normal operating state.

Alternative embodiment with system generated calls

A well-known problem with bulk matching systems is the low probability that a bulk buyer and a bulk seller enter an order simultaneously. Many aspects of the present invention are directed to solving the problem after this first trader has entered an order; but does not provide guidance on itself when this first participant should be maximally encouraged to enter orders.

The ability to focus on interest in a timely manner is especially important to the desire to obtain the greatest possible price improvement through the mechanisms described herein.

In an alternative embodiment, the system operates as described above, but additionally generates a "call" event that oftentimes concentrates trader interest when there is a prompt for both buy and sell interest in a security. In another alternative embodiment, no valid flag is sent and the call is the only time interest event. The call is preferably placed by an algorithm that determines when the highest likelihood of execution is most likely. It is desirable not to utilize unbalanced trading information (e.g., revealing the presence of buying interests but not selling interests) to avoid exposing the information to the trader, thereby giving the trader the perception that the order they enter into the system is causing an unwanted information event that is outside their direct control range.

The purpose of the call is to entice the trader to enter an order when execution probability is greatest. For example, if the average fill rate of the first trader entering an order for a given security is 5%, the fill rate of that security at the time the call is opened may be 10% or 15%; in contrast, the fill rate without a call will be below 5%; and the total average fill rate of traders who enter orders randomly, regardless of any call, is 5%.

At a minimum, such an alternative embodiment generates a call that focuses attention on the order entry of securities when both traders enter orders but are out of match with each other because their orders are entered at different times. Other examples of situations in which the system may generate a call will be described below. To avoid information leakage about orders entered into the system, in embodiments with BPR, the calls are reported at a pre-scheduled time, e.g., a 60-second BPR update, rather than at the occurrence of an order event.

	Description of the invention	Type (B)
			Symbol	First class market name of securities	char[5]
TimeStamp	When calculating BPR	HHMMSSCC
			QuoteTime	Time of last report update before calculating BPR	HHMMSSCC
LastSaleTime	Time of last market display system printing before calculating BPR	HHMMSSCC
			NationalBid	In cents as unit	FLOAT.2
NationalOffer	In cents as unit	FLOAT.2
			BlockBid	In cents as unit	FLOAT.2
BlockOffer	In cents as unit	FLOAT.2

Call

Opening/closing

Boolean

The algorithm for generating the call is preferably based on the following principle.

● are not triggered by order entry. The opportunity to place a call is evaluated at a pre-scheduled time. This eliminates the concern that information will leak if the trader wants to see if his or her own order can cause a call to be placed. It also prevents such traders from discovering information about the book. For example, assume that the system rules are that when both a buyer and a seller receive an order, a call is placed. If the buyer wants to trigger a call by order entry, he will find that the seller has recently been in the system. By placing the call at a pre-arranged time, the call is no longer directly related to the trader's order, and its interpretation does not necessarily reveal any information about the parties to other orders in the book.

● 1 min minimum life. Once the call is initiated, it lasts for a time sufficient for the trader to react and respond to the call.

● two sides. A call is only made if there is evidence that both parties are interested in a large block. This reduces potential gaming.

● there may not be orders. When there are no valid orders in the system, a call may be generated; thus, the trader may not be able to infer the presence of an order in the system by monitoring when a call is placed.

● do not disclose rules. The rules for the system to place calls are preferably modified periodically and are not disclosed to participants to reduce the risk of a parasitic trader attempting to infer information about the system's book from the timing of the calls. Periodic updates also give the system operator flexibility to adjust the rules to maintain reasonable call frequencies.

The following data is preferably available for the purpose of making decisions when a call should be made.

● carry the remaining amount of tickets.

● opens the order.

● due order.

● trade.

● market shows a block print on the system.

● transaction volume is unusually high for repeated printing on market display systems.

Rule-based method for placing a call

The first alternative embodiment makes use of a rule-based approach for making a decision when a call should be generated. For each code, an activity evaluation process is performed along with the BPR update process.

If no calls have been made, the rules given below are preferably applied to decide whether the code should be called depending on the activity (order, trade, etc.) in the system and depending on the market. If any Boolean rule is true, the code is called.

If the code has been called, the code is called for at least <60> seconds (configurable global parameter), and the contra-present flag is not present in the security, the system preferably removes the call.

The rules that result in a call are listed under the following pop-up points.

O orders have been entered and expired. Thereafter, the other party enters another order. At the next regularly scheduled time, it is checked whether a call was issued under this code in the last 30 minutes (ActiveMaxDelay 1 configurable), and if not already, a call is issued under this code.

O orders have been entered and expired. After that, over printing (greater than 10000 shares or $250,000, and these are configurable parameters) is detected on the mood display system and no call has been issued yet for the last 90 minutes under this code (configurable ActiveMaxDelay 2).

O self-determine: the help desk operator prints the code and clicks the button.

Enter order and have ticket present on the other side.

Enter order under the code of the last <30> minute trades.

Passively pricing resident orders and new orders with aggressive prices have been reached.

The resident sell order is aggressive and detects duplicate prints on the line status display system, indicating collective purchases on a large amount of issue plates; alternatively, the same is true for buy orders in the system, and vice versa, as is evidence of bulk sales in the market.

The above list is for illustration only and is not exhaustive. Other rules for identifying when a greater likelihood of a transaction exists will be readily understood by those of ordinary skill in the art.

Scoring function method for calling

As described next, another alternative embodiment with calls utilizes a scoring function to determine when to generate a call.

For each code, a call evaluation process is performed along with the BPR update process. If no calls are currently made under this code, the system calculates the activity score and threshold for the code as follows. If the score exceeds a threshold, the system preferably generates a call for this code.

If the code has been called, the code is called for at least <60> seconds (configurable global parameter), and the contra-present flag is not present in the security, the system preferably removes the call.

The system preferably calculates the score in two steps.

Step 1: buyer interest and seller interest in securities are calculated by adding weights associated with the following conditions.

● OpenOrderConditon. Buy (sell) orders that are currently open and aggressively priced.

● PassionOrderConditon. Buy (sell) orders that are currently open but are passively priced.

● ExpiredOrderConditon. Currently out of date buy (sell) orders.

● TicketConditon. With a remaining number of buy (sell) tickets.

● Block TappeConditon. The most recent bulk execution on Cloud 9.

● MarketPrintCondition. Bulk printing on a market display system of at least < BlockQty ═ 1000> stock or < BlockValue ═ 250,000>, occurs since the last scheduled call evaluation time, prints above (below) the intermediate price.

● random refresh detection. Duplicate printing above (below) the intermediate price since the last call evaluation time, at a speed exceeding < LiqudityRation 2 times the average trading volume of the securities, for a total number above < BlockQty 1000> stock or < BlockValue 250,000 >.

● WatchListCount. The number of traders who contain this code on their watch list.

The following table gives examples of reasonable configurations of the weights.

	Description of the invention
			OpenOrderCondition	Orders within BPR	20
PassiveOrderCondition	Negative orders	10
			ExpiredOrderCondition	Due order	5
TicketCondition	Ticket	4
			BlockTapeCondition	Cloud9 market information display system	3
MarketPrintCondition	Bulk printing on a market display system	2
			RandomRefreshCondition	Buying (selling) pressure on the market	1
WatchListCount	Monitoring the number of traders on the table containing this code	INT

Step 2: the code activity score is calculated as the product of the buy interest times the sell interest.

The system preferably calculates the threshold as follows. If the code has never been called, the threshold is equal to zero. If the code has been called before, the threshold value of this code is equal to an exponential function of the time since the last call that expired this code:

Threshold＝MaxThreshold*EXP(-Beta*TimeDelay)

the parameters MaxThreshold and Beta are preferably configurable per security.

In embodiments with system calls, the system may match orders continuously as in the above-described embodiments, or accumulate orders without any match occurring until the scheduled call period has elapsed, and release them to the execution engine at that time in the order of party, price, and time as described above. The latter approach creates a call auction environment that can be run in conjunction with the conventional trading that occurs in the present system, wherein the system automatically generates calls when activity is found that adjusts such steps, then holds all orders for the duration of the call, accumulating enough orders to get the best chance of price improvement for aggressive participants. In this embodiment, for example, consecutive matches may be in effect for a low minimum number requirement (e.g., 100 shares) and when a prompt is found that both parties are interested in a block, a block auction (e.g., 100,000-share call is automatically triggered when a delayed call is executed, the system preferably limits itself to a single clearing price per call auction by arranging orders as described above and entering them one-by-one into the execution engine 50, when the first transaction is made, re-pricing all subsequent orders as needed to ensure that when this call occurs, their limits are not more aggressive than the first transaction price.

Alternative embodiment with trigger ACTIVE SYMBLOL message

In an alternative embodiment, for the alternative embodiment with ACTIVE SYMBLOL notification, the system operates as described above, except that the activity code message is sent only to traders who have provided approved trade interest information indicating a potential interest in buying or selling a block of such securities. For example, such approved trade interest information may be a drawn copy of the execution report issued by the broker after each trade, and the selection criteria may be that the company has net bought (or sold) at least 10,000 shares in the last 30 minutes. Other examples are broadly described in the following co-pending U.S. patent applications: 09/585,049, filed on 6/1/2000; 09/750,768, 12/29/2000; and 09/870,845, filed on 3/31 of 2001, which is hereby incorporated by reference in its entirety.

Alternative embodiment with CONTRA PRESENT Notification

In an alternative embodiment the CONTRA PRESENT notification also displays the price of the return disc, so that the party receiving the notification can directly decide whether to accept the return disc instead of having to propose the price.

Alternative embodiments of the present system use different rules for determining who is eligible to receive the CONTRAPRESENT notification, particularly interesting for the quotation rules and order display rules. The quotation rules require that market participants be quoting to represent their best priced orders with their quotations; and order display rules require that if more than one other party is shown a price, it is necessary to show the price and make it applicable to the entire market. These two rules form a potential obstacle to deploying the system body of the PRESENT invention if one decides to view the CONTRA PRESENT notification like a quote. An alternative embodiment addresses this situation by showing a CONTRA PRESENT notification to only one principal; for this purpose, the order with the highest matching priority is selected. The opposite approach is to show the CONTRA PRESENT notification to all users regardless of whether they own the order in the system. Of course, only the user who has an order in the system can infer the party interested in the party; for example, a user in the system having a buy order will know that there is at least one seller and possibly a number of other buyers in the system. A user without an order in the system will know that there is at least one buyer and at least one seller, but not which party is more aggressive than the other. Since such two-way information does not harm the participant's trading interest, releasing this information into the entire market is an acceptable leak of information.

While the embodiments shown and described herein are fully capable of attaining the objects of the invention, it is evident that various alternatives, modifications and variations will be apparent to those skilled in the art in light of the foregoing description. Such alterations, modifications, and variations are intended to be within the scope of the invention, and it is to be understood that the embodiments described herein are illustrated by way of example only and not by way of limitation.

Claims (23)

1. A method of facilitating a trade of securities on a computer system, comprising the steps of:

electronically receiving market data including prices for securities;

calculating a reference price for the security based at least in part on the market data;

electronically storing the reference price in a computer-readable medium;

electronically receiving a first order from a first user relating to said security, wherein said first order comprises a first price limit and a first quantity limit;

electronically storing the first order in a computer readable medium;

electronically receiving a second order from a second user relating to said security, wherein said second order is a counterpart of said first order and comprises a second price limit and a second quantity limit;

electronically storing the second order in a computer readable medium; and

executing a trade comprising the first order and the second order at a price that differs least from the reference price, wherein the trade is subject to the first and second price and the first and second quantity definitions.

2. The method of claim 1, further comprising: sending an electronic notification to the first user if (a) the second order is not priced enough to match the first order, and (b) the first order is priced at least as aggressively as the reference price, wherein the notification notifies the first user that a contra order has been entered in the system.

3. The method of claim 1, wherein the second user is allowed to increase price aggression only after a predetermined period of time has elapsed.

4. The method of claim 1, wherein the reference price is based on a recent market price.

5. The method of claim 1, further comprising displaying the reference price to a remote user through a graphical user interface.

6. The method of claim 2, further comprising calculating a block price range, and wherein the notification is issued only if the second order is at least as aggressive as a negative end of the block price range.

7. The method of claim 6, wherein the step of calculating a block price range is based on recent volatility of the securities prices.

8. The method of claim 6, wherein the step of calculating a block price range includes predicting a price range likely to occur within a first predetermined period of time.

9. The method of claim 8, wherein the block price range is recalculated at intervals approximately equal to the first predetermined period of time.

10. The method of claim 6, wherein the step of calculating a block price range is based on recent or current market prices.

11. The method of claim 6, further comprising the step of: if the first order is priced aggressively at least as much as the negative end of the block price range, an activity code notification is issued after receiving the first order.

12. The method of claim 2, further comprising: after receiving the second order, sending an electronic contra order notification to the second user indicating that a nearly matching contra order is valid within the system.

13. The method according to claim 12, wherein said second user receives said contra order notification only after a predetermined period of time has elapsed.

14. A method of facilitating a trade of securities on a computer system, comprising the steps of:

electronically notifying one or more users of the system accumulation period to receive an order for a security;

electronically receiving market data including prices of said securities and calculating a reference price based at least in part on said market data;

electronically storing the reference price in a computer-readable medium;

electronically receiving a first order from a first user relating to said security, wherein said first order comprises a first price limit and a first quantity limit;

electronically storing the first order in a computer readable medium;

electronically receiving a second order from a second user relating to said security, wherein said second order comprises a second price limit and a second quantity limit;

electronically storing the second order in a computer readable medium;

electronically notifying said first user of the order being placed into the system; and

executing a trade comprising the first order and the second order at a price that differs least from the reference price when the cumulative time has elapsed, wherein the trade is subject to the first and second prices and the first and second quantity limits.

15. The method of claim 14, further comprising electronically placing one or more calls to orders entered in a given security.

16. The method of claim 15, wherein the calls are placed at regular intervals.

17. The method of claim 15, wherein said calls are made at regular intervals for securities whose activity indicates an interest in buying and selling a block of securities.

18. The method of claim 17, wherein the activity comprises receiving an order to buy a security and an order to sell a security.

19. The method of claim 17, wherein the activity comprises receiving an order to buy a security and evidence of market data for a block selling interest.

20. An electronic system for facilitating trading of securities, comprising:

a transaction facilitating computer system comprising a facilitator module, a financial information exchange server, a transaction database and an analysis server which functions to calculate a reference price for a security,

wherein the transaction facilitating computer system is in communication with a financial information exchange network and a communications network,

wherein the financial information exchange network is in communication with the communication network,

wherein the communication network is in communication with one or more user terminals; and

an execution engine in communication with the transaction facilitating computer system,

wherein the execution engine functions to minimize a difference between an execution trade price of a security and a reference price of the security.

21. The system of claim 20, wherein the analytics server evaluates orders for securities by comparing price aggression of orders with a reference price for the securities.

22. The system of claim 21, wherein the transaction facilitation computer system is operative to: if the first order is at least as aggressive as the reference price, a first user having placed the first order in respect of the security is sent a notification that the transaction facilitation computer system has received an order for the first order that is the contra-party order.

23. A system as claimed in claim 21, wherein the order is required to be a multiple of a block amount greater than the average order amount received by the brokerage trader.