KR20080094767A - Anonymous block trade matching system - Google Patents

Abstract

Disclosed is an anonymous block trade matching system which allows users that wish to cross large blocks of stock to submit orders, or indications of interest, with the option of utilizing market peg benchmarks or future price cross benchmarks. Orders submitted may be subject to minimum thresholds, including a threshold requiring that the order represent "X" % of average daily volume. After submission of a firm order in the system, an alert is generated to provide the order data to other users with potential to cross the order. Visibility of order data by other users may be restricted based upon a data interaction group to which the ordering user or the other user belongs. The system may provide users viewing order data with a capability of negotiating with the submitting user via a restricted two-way messaging interface. Flat rate and rebate/fee cost models may be utilized as a means for charging a user for access to the system.

Description

Anonymous Block Trading Matching System {ANONYMOUS BLOCK TRADE MATCHING SYSTEM}

The present invention relates generally to the field of computer systems, and more particularly to new computer systems for promoting block trading securities trading.

Block trading, also referred to as "crossing," is a known type of securities trading in which a transaction is private, unlike a public auction market. Block trading allows sellers and buyers to reduce transaction costs such as tickets, execution, and settlement costs. Although block trading has mostly been done through party negotiations, several matching engines and alternative trading systems have been known in the art that match securities buyers with sellers and securities sellers with pools of liquidity.

Some of these matching engines, known as Instinet, VT and CBX ("Instinet Systems") provided by Instinet, allow users to submit anonymous orders. The system distributes these order notifications to other users on the system who may be interested in trading with the user that caused the order alerts. If order notifications are distributed and negotiated among the parties, the parties do not know each other. In this regard, order notifications allow parties to find a natural counterpart to trade while controlling information leakage and protecting their trading strategy.

Users of such a system, while negotiating actual sizes and prices with conventional counterparts, seemingly only show minimum fulfillment transactions and prices, and control order information visible to the market.

However, Instinet systems and other matching engines that provide block trading are limited in many ways. They provide a continuous means of over-the-counter trading, but they do not allow you to place orders using market peg benchmarks or future price cross benchmarks through web-based terminal applications. These systems provide a means of sending notifications to inform subscribers of potential trading opportunities, but there is no means in the system to allow the user to control which users or types of users will receive such notifications. . In addition, systems that provide block transactions generally provide only limited means of negotiation between the parties, and such negotiations are only available to customers utilizing a private trading platform on a private data network.

It is therefore an object of the present invention to provide an improved anonymous block transaction matching system.

It is a further object of the present invention to provide a system that allows participants to anonymously trade large quantities of international or domestic stock blocks to reduce ticket, fulfillment and transfer costs while reducing market impact and spread costs. To provide.

In a preferred embodiment, the present invention provides an anonymous block trading matching system that allows users who wish to trade a large number of stock blocks to submit an order or indication of interest with the option to utilize market peck benchmarks or futures price cross benchmarks. To provide. Orders submitted may be limited by the minimum size threshold. After a confirmation order has been submitted to the system, a notification is generated to send order data to other users who will potentially trade for that order. Whether other users can view the order data can be limited based on the data interaction group to which the ordering user or another user belongs. The system allows a user viewing the order data to negotiate with the user submitting the order through the limited interface of two-way messaging. Flat rate and rebate / fee cost models can be utilized as a means of charging users to access the system.

Accordingly, the present invention provides a method of trading mutual benefits, in which all of the trading parties can benefit from trading directly with a conventional counterpart.

The above or other objects, features and advantages of the present invention will become more apparent from the more detailed description of the preferred embodiments described in the accompanying drawings. In the drawings, reference characters indicate the same parts throughout the drawings. The drawings are not always to scale, emphasis is drawn to illustrate the principles of the invention.

1 is a schematic block diagram illustrating a system according to an embodiment of the present invention.

2A is a diagram of an interface in which a system receives an order in accordance with an embodiment of the present invention.

2B is a diagram of an interface in which a system receives an order in accordance with an embodiment of the present invention.

3 is a high functional flow diagram illustrating a processor for generating and distributing notifications.

4 is a diagram of a web application interface according to one embodiment.

5 is a diagram of a two-way messaging system interface.

6 is a diagram of a search window in accordance with one embodiment of the present invention;

Reference will now be made in detail to the preferred embodiments of the present invention, which are set forth in the accompanying drawings.

The present invention is described below with reference to a block diagram and operation diagram of a method and apparatus for manufacturing and using a block transaction matching system according to the present invention. Each block in the block diagram or operation diagram and a combination of blocks in the block diagram or operation diagram may be implemented through analog or digital hardware and computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, ASIC, or other programmable data processing device such that the instructions are executed through a processor of the computer or other programmable data processing device and are in block diagram or operation diagram. Implement the functions / operations described in. In some alternative implementations, the functions / acts indicated in the blocks may occur out of the order indicated in the operational diagram. For example, two blocks marked as concatenated may in fact be executed substantially concurrently or the blocks may sometimes be executed in the reverse direction depending on the functionality / operation in question.

1 illustrates an embodiment of an anonymous trading matching system 10 for trading a typical bulk stock block in an international or domestic market. The system 10 provides users with the ability to submit orders for block transactions during subsequent trading hours. If there is a firm order, the order data for this order may be included in the block match "alert" or "indication of interest (IOI)", which is optionally distributed to other users and cross-traded. Inform these users of the opportunity to start a cross trade.

The block matching engine 12 utilizes an algorithm for matching the orders described below. A core database 14 is provided for storing history information about transactions and tracking customer's transaction history. In one embodiment, the core database is a notification generator. However, as will be appreciated by those skilled in the art, the notification may be generated by any server in the system without departing from the spirit and scope of the invention. Customers access the transaction matching system 10 and communicate with an external trading system 18 that communicates with the in-house trading platform 16 via an interface with the in-house trading application 24 that communicates with the in-house trading platform 16. Place an order and / or receive a notification through an interface or through a web client 20 that connects via the Internet with the web infrastructure server 22.

External trading system 18 may communicate with transaction matching system 10 using appropriate standard or private ordering protocols. One example of a suitable protocol is the Financial Information eXchange (FIX) protocol published by the FIX Protocol maintained by the FIX Protocol Limited Company in London, England. This FIX protocol is a known electronic communication protocol for international real-time exchange of information on stock trading and markets. FIX messages are made up of many fields, each of which is a tag value paring separated from the next by a delimiter SOH. TAG is a string representation of an integer representing the meaning of the field. This value is a byte string with a specific meaning for a specific TAG. For example, "TAG 48" is a security ID and a string identifying security, and "TAG 22" is an ID source and an integer indicating an identifier class being used. In most cases the value is readable text. However, the fields may be encrypted so that the value is a pure binary value and may contain the generic delimiter SOH. The length field always precedes the binary fields. The FIX protocol defines the meaning for most TAGs, and the scope of TAGs is reserved for private use among consensus. The FIX protocol also defines a set of fields for preparing specific messages. Some of the field sets are mandatory under the above protocol and others are optional.

Web infrastructure server 22 provides a secure interface to web clients accessing the system via the Internet and sets up user level permissions. The web client 20 runs an Internet delivery web application that allows users to view trading opportunities in the form of "alerts" described in detail below. The web application allows the user to set filters to prevent receiving a huge number of notifications for market segments that are not of interest to him. The web application may also include an instant messaging function that allows clients to communicate with each other using permitted phrases to facilitate transaction negotiation, as described in detail below. The web application may also include an enhanced search screen that allows users to enter their selection criteria to display orders submitted to the system. The web application of one embodiment builds real-time data feeds from the core database so that changes in the core database that occur during the day can be immediately reflected at the web front end. Representation of data by the web application can be accomplished by configuring to display in four window types: a stock listing window displaying an ordered list of live, traded, canceled and expired orders on the system; A market depth window showing aggregated data with prices for ongoing, traded, canceled and expired orders; A notification window displaying an IOI associated with orders submitted to the system; And a bidirectional message window used to negotiate with participants for existing orders, expired / cancelled orders and traded orders.

2A and 2B illustrate diagrams of an interface through which a system receives a security order, according to one embodiment. Current market data for the security is displayed in the upper three parts of the interface. At the heart of the interface is a series of fields with selection options. In the "Quantity" field, the user can enter the quantity associated with the order. The "Display Quantity" field is a combo control that allows the user to enter a display quantity that meets the minimum display criteria with the option of selecting system values using drop down. To provide. Such a system value may be, for example, "1000", "2000", "3000", "4000", "5000", "10000", "15000", "20000", or "25000". The default value can be set to "All", in which case the entire order will be displayed. The "Expiry" field provides combo control that allows the user to enter an expiration time for the order. Users can use the lookup to access a list of system values. These system values can be, for example, "Day", "GTD", "Blotter", "+5 minutes", "+10 minutes", "+1 hour", or "IOC". have. The required default value can be set to "Day".

The order screen of FIGS. 2A and 2B of one embodiment includes a "Display Price" field that informs the user to select a custom order associated benchmark. Orders are for example market peek benchmarks "Mid", "Bid", "Ask" and futures price cross-benchmark "VWAP", "Open (Open) "," Close "can be submitted. By providing the ability to submit orders using these benchmarks during ongoing trading hours, the system can provide a mutual benefit trading solution whereby all trading partners can benefit from direct trading with their usual counterparts, This can provide a means to reduce ticket, fulfillment and transfer costs by eliminating intermediaries while reducing market impact and cost proliferation.

If a user enters a major peek benchmark (eg, "Mid", "Bid", or "Ask") in the "Display Price" field of Figures 2A and 2B, the system will place a hard limit on the order. option). In this case, the main peck benchmark price fluctuates as the market fluctuates, but once the market exceeds the upper limit price, the user is eventually protected by their strict limits. The order will be displayed using a peek benchmark value, such as MID, in alphabetical rather than the actual price value. If the market goes beyond the user's strict limit, the order type will automatically change to a strict limit order and display a strict limit price in the form of a number. If the market moves back favorably, the order will revert back to its alphabetic value. If a match is found (who entered the order with the same benchmark value on the other side), the transaction will be closed to the benchmark primary value specified at the time the match occurred.

If a user enters a major future cross-price benchmark value such as "VWAP", "Open" or "Close" in "Display Price" in the fields of Figures 2A and 2B, for example, specify a strict restriction. No option is given. The order will be set to the selected benchmark, and as soon as a match is found (who entered the order with the same benchmark value on the opposite side), the indicated fill will be delivered to both parties at the main market final closing price. will be. If a major exchange issues an official price that the user has listed as a futures cross benchmark, a trade correct will be sent to both participants at the official cross price.

The system may be configured to enter an order for each stock that obeys one or more minimum thresholds for each share in order to participate in the block matching functions provided by the system. These thresholds include the "% ADV" threshold and the Share Quantity threshold. In order to meet the% ADV threshold, orders must be expressed in 'X'% of the average Daily Volume. In order to meet the stock quantity threshold, the order must be 'X' stocks. If an order is entered into the system that does not meet the required threshold, the system may reject it. The thresholds for a particular stock ordered can be set to any value, but will generally be based on the liquidity of the stock and the price level of the ordered stock.

The system may be configured to provide users with the convenience of including their order data in an indication of interest or block match notification, maximizing the likelihood of finding a suitable party to trade with. In various embodiments, the system divides users into four separate data interaction groups, and makes order data visible to users according to the groups to which they belong. In one embodiment, the four groups are Buy Side, Sell Side, Market Maker, and Dark Provider. These groups and the extent to which they can view orders in the system are summarized in the table below.

group type Visibility Buying side Institutional General Hedge Funds All buy and sell orders appear. Secret orders do not appear. Sell Side Broker / Dealer Prop Desk Limited at the discretion of the participant who posted the liquid asset Market maker Mayor Limited at the discretion of the participant who posted the liquid asset Secret provider Participants who want to make their spells invisible Orders from all groups do not appear

3 is a higher functional flow diagram illustrating a processor for generating and distributing notifications. The process begins with a system reception of a firm order in step 310. Users must enter a firm order into the block matching system to trigger a notification / IOI. In step 312 the order data is first sent to the core database. In step 314, the order data is examined to determine whether the user requesting the order has designated himself as the secret provider. Secret providers cannot see any order data for orders submitted to the block matching system, but can instead interact with the orders as a hidden participant. Their orders are not visible to anyone in the participating groups. Thus, if the user requesting the order is a secret provider, no notification is generated and the notification generation process stops at step 316. Otherwise, the process continues to step 318. In step 318, order data is examined to determine whether the user has added a "hidden" command to the order. If the user added a "hidden" command when placing an order, the order would not be displayed in the order book and no notification would be generated.

If the order is not designated as hidden and not filed by the secret provider, the process proceeds to step 322 to generate a notification. The content of this notification is described below with respect to FIG. 4. With continued reference to FIG. 3, the order data is then examined to determine whether the user includes a sell side command. According to one embodiment, orders submitted to the system are visible only to the buy-side users by default. However, buy-side users have the option of making their orders visible to the sell-side / market makers by adding a "sell-side" command to their orders. This sell-side command may be displayed at the time of order, for example by checking the "sell-side" box shown in Figures 2A and 2B. Alternatively, such a command may be automatically set by the system according to the user's user profile. Sell-side users can enter orders into the system, but their orders will always be visible to the buy-side. However, they can hide orders from other sell side / market makers by not adding a “sell side” order to their orders.

Based on the user's transaction history data stored in the core database 14 (FIG. 1), specifically, the amount of transactions made by a particular user within a particular history time frame (e.g., last month, last four months, last six months, etc.), A "tier" can be assigned to a particular client. As a useful use of the system, the system may be configured to provide notifications to lower tier customers to higher tier customers, such as those with a high transaction volume history. In one embodiment, there are two layers of users layer 1 and layer 2. Tier 1 users receive notifications before Tier 2 users and other participants. In one embodiment, the system is configured to send notifications to layer 1 users one minute prior to layer 2 users. The system may be configured to allow users to achieve a predetermined minimum transaction amount within a specific time interval suitable for layer 1 notifications. For example, users may be required to trade on the system at least once in the past week. The system checks alert subscriptions to determine which users will receive the notification first when a new order is submitted to the system. The system may be configured such that layer 1 notifications are available only through inhouse front ends, and all external notification applicants are assigned to layer 2.

4 is a diagram illustrating an example of a web application interface including a notification window, a stock list window, and a negotiation window, according to an exemplary embodiment. According to one embodiment, the notification window provides notification / IOI for orders according to the user's hierarchical target level and visibility of the client group (eg, buy-side, sell-side, or secret provider) when orders are submitted to the system. Display. The window can be set to a permanent display window by default. However, the system can be configured to allow a user to right-click on a window and then select 'set as pop-up window' if the user prefers to open the window at the same time as receiving a new notification. have. The notification window displays stock, side, and quantity for each new notification / IOI. The system may be configured to expire and remove the notification / IOI in the notification window after a predetermined period of time, such as two minutes.

As shown in FIG. 4, a stock listing window may be provided in the web application interface to view and interact with current and historical order data. The interface allows users who have subscribed to view order data for orders submitted to the system to view transactions, minimum and expired order history and ongoing orders for a specific time period, such as for the last 30 days. Each order is displayed on a separate line, with ongoing orders sorted by date and time followed by a history of transactions, canceled and expired orders, also sorted by date and time. The system may be configured such that when a new ongoing order for a stock displayed in the user's stock list window has been added to the system, the order line is displayed in a separate color, which color may be for a specific time such as two minutes. Gradually disappears, indicating the original color of the spell below.

Through a two-way messaging system, where negotiations on past orders data as well as on-going orders are activated, for example via double-click on a particular order displayed in the stock list window or the notification window shown in FIG. It is provided by activating a button or other control associated with the order. 5 shows a diagram of a two-way messaging system interface. The two-way messaging system may be provided in a real time messaging system such as, for example, instant messaging, or may be provided in a non real time messaging system such as an email system. The two-way messaging system may be provided as part of a web application running on the web client 20 (FIG. 1).

Users use the two-way messaging interface of FIG. 5 to target orders of interest using a limited keystroke or button press to select a target of interest using the hardcoded phrases allowed by the system and to send and receive limited messages with the owner of past orders. Can be used. Keyboard stickers may be provided to users to associate certain keys with certain permission fiction. For example, the "S" key may be associated with the phrase "Sorry not at present" and the "W" key may be associated with the phrase "Will you deal at". Hard coded phrases may be implemented in the form of a corresponding series of phrases associated with the series of soft buttons appearing on the interface of FIG. 5. In this embodiment, the system limits parties to communication using a limited number of phrases associated with numeric keys and a limited number of buttons on a user's keyboard. Preferably, the numeric keys are not limited.

Below is an example list of messages allowed from the negotiation window using either a soft button operated by a mouse (eg, Sorry) or a hot key operated by the keyboard (eg, W).

Button label Full text message Keyboard hot keys Yes: Yes Y No: No N Will: Will you deal at _? (Do you want to trade on _?) W Sorry: Sorry, not at present (Sorry, but not present) S Best: My best price is _ (Preferred price is _) B Call: Need to make a call, be right back C Limit: Currently limited at _ L Neg ID: Requests a negotiation ID I

The negotiation window of FIG. 5 shows negotiation between two participants. The first participant sent a message to the owner of an order of WTB.L, Sell, 1,000,000, 'will you deal at 22.75?' The order owner is trying to respond with a 'Sorry not at present'.

When negotiations are made in price and quantity, users can request a system-generated negotiation ID that can be attached to a firm order that secures the order so that it does not deal with someone other than its own counterpart. This ID can be a system generated by the web application and can be seen by both users. Both users submit an order with agreed order parameters (quantity, price) and add a negotiation ID to their order in the negotiation text field. This effectively locks orders for two participants and prevents the user's orders from being traded with someone other than the one they negotiate with. Completed orders are removed through external transaction removal (Figure 1).

6 illustrates an example of an enhanced search window in accordance with one embodiment of the present invention that allows a user to enter selection criteria for displaying orders submitted to the system. Once logged into the web application, the user encounters a search window. You can use this window to build ad hoc-based queries, or search terms that you want the user to simply select a query name and select the "Go" button or perform similar controls in subsequent logins. Can be set and the query saved.

In the search window of FIG. 6, the "Symbol" field provides a means for a user to identify a particular stock, to identify a plurality of stocks using a comma separator, or to select one or more stocks from a list. to provide. The "Symbol Type" field allows the user to select the type of symbol entered in a symbol field, such as "Instinet Symbol", "RIC", "Cusip", or "Sedol", as well as other information such as Bloomberg. 3 Identify references to third party vendor products. The "Exclude Alerts" field gives the user the ability to exclude orders for which alerts were generated from the search results. The "Side" field provides a look down list that allows the user to limit the search to either the buy side or sell side orders. The "Order Type" field allows the user to limit the search to one of the ongoing, traded, canceled or expired orders. The "Quantity" field provides a means for the user to specify a range, for example 10,000-20,000. The "Instrument Type" field allows the user to specify the type of tool to search for, eg UKI ITE, USE, USEO, or CAE. The "Market" field allows the user to specify a particular market, such as U.K. Or to restrict the search to U.S. The "Region" field likewise allows a user to limit the search to multiple regions using a specific region, such as Europe, United States, or Asia, or comma delimiters. The "Currency" field allows the user to limit the search for orders to a specific currency, such as GBP, GBp, USD, JPY, HKD, EUR, CHE, NOK, DKK, ZAR or all. The "% ADV" field allows the user to specify a percentage range of order quantity for a particular stock, eg 5% to 200%. The "Include Hidden" field allows the user to include orders placed in the search results with the "hidden" command discussed above. The search is executed by the above criteria via the "Search BlockMatch" button, and a list of orders in the system meeting these criteria is returned.

The system can be configured to provide users with a mutually cost-benefit model for two parties who wish to trade large amounts of stock blocks in the open market. In this regard, the system can provide two cost model options for users: a fixed fee cost model and a rebate / repair cost model.

The fixed fee cost model option provides users with a fixed fee cost model accessing the system a fixed fee fee per transaction, such as 2.5 bp per transaction for orders placed on the system through DMA orders or the owner of the system owner. I can suggest. Orders submitted to the system using one of several value-added algorithms that automate the access of liquid assets can be offered at different, higher fixed rates, such as 3 or 4 bp.

In the rebate / maintenance cost model option, users can conduct a transaction where the purchaser obtains a list price of, for example, 10 minus 2.5bp and the seller obtains a list price of 10 minus 7.5bp. Accepting the rebate / reward model is configured to automatically calculate customer transactions as rates or rebates based on each transaction based on which client is the provider or acceptor of liquidity. Alternatively, the system can be configured to ensure that all transactions are processed under a flat rate model and manually rewrite each rate to a new rate at the end of the day or month, taking into account all rebates / rewards.

Thus, the system allows for participants to post 'take liquidity' capability directly to the system, for example, at a fixed cost of 7.5 bp, while 'liquidity providers' for example, for orders. It can be configured to benefit from a 2.5b rebate. The system may be configured to allow participants who trade in and post the acquisition of current assets to be about the same, accessing the system at a fixed rate, such as the central point of the total fee for direct posting and acquisition of current assets of all transactions, for example at 2.5 bp. Can be.

While the invention has been particularly shown and described with reference to the preferred embodiments, those skilled in the art will recognize that various changes in form may be made without departing from the spirit and scope of the invention.

Claims (43)

At least one server configured to receive order data for a security order over a network, the order data comprising a user's specification of a price benchmark for the order, wherein the price benchmark includes a strict limit ( selected from a group consisting of one of a peg value having a hard limit, a peg value having no hard limit, or a future cross price; A core database storing said order data, said order data comprising said price benchmark; And An alert generator configured to send an alert to the at least one prospective trading party using the order data to anonymously describe the order Anonymous block trading matching system comprising a. The method of claim 1, And the at least one server is further configured to receive the order data via a private network. The method of claim 1, The at least one server is further configured to receive the order data over a publicly accessible network. The method of claim 1, Wherein the at least one server comprises a first server for receiving the order data over a publicly accessible network and a second server for receiving other order data over a private network. The method of claim 1, Matching engine to find opponent orders that meet the benchmark value Anonymous block trading matching system further comprising. The method of claim 1, And the notification generator is configured to generate the notification such that an alphabetic benchmark value that is not an actual price value is displayed within the notification to the prospective trading party. The method of claim 6, The price benchmark includes a peck value, the alphabetic benchmark value is selected from the group consisting of MID, BID, or ASK, wherein the benchmark value refers to a major market for the price of the security, Anonymous block deal matching system. The method of claim 6, The price benchmark includes a futures cross price and the alphabetic benchmark value is selected from the group consisting of VWAP, OPEN or CLOSE, wherein the VWAP benchmark value refers to a price determined at the discretion of the owner of the system, And the OPEN and CLOSE benchmark values refer to a major market for the price of the security. The method of claim 1, An anonymous block transaction matching configured to automatically change from a price benchmark order type to a strictly restricted order type when the exchange in which the securities are traded moves above the user's specified strict limit. system. The method of claim 9, After the change from a price benchmark order type to a strict limit order type, the notification is configured to display the strict limit price in numerical form. The method of claim 9, After said change of order type, said order type is automatically configured to return to said price benchmark order type when said transaction moves below said specified stringency limit of a user. The method of claim 11, And the notification is configured to display an alphabetic benchmark again after the change from a strictly restricted order type to a price benchmark order type. The method of claim 8, Anonymous block trade matching configured to send trade corrects to two participants at an official cross price after a major exchange issues a quoted price for an ordered securities using the futures cross benchmark. system. A server configured to receive order data for a security order; A core database for storing the order data; And And use the order data to send a notification describing the order anonymously to a plurality of prospective parties, optionally selecting the notification based on an indication in the order data of which types of users receive the notification. Notification generator configured to send to the plurality of prospective parties Anonymous block trading matching system comprising a. The method of claim 14, And the notification generator comprises a database. The method of claim 14, And the indication in the order data of which types of users receive the notification includes an indication that the notification will be hidden from a group of users. The method of claim 16, The anonymous block transaction matching system, wherein the group of users includes all users. The method of claim 16, The anonymous block transaction matching system of this group includes fewer users than all users. The method of claim 14, And the indication in the order data as to which type of users receive the notification comprises an indication as to whether the selling side users receive the notification. The method of claim 14, The notification generator sends the notification to the buy-side users by default, and the indication in the order data of which type of users receive the notification indicates an indication of whether the sell-side users receive the notification. An anonymous block trading matching system that includes. The method of claim 14, And the indication in the order data as to which type of users receive the notification comprises an indication as to whether market maker users receive the notification. The method of claim 14, And the notification generator is configured to prevent a secret provider from viewing the order data. A server configured to receive order data for a security order; A core database for storing the order data; And Send a notification to the plurality of prospective parties anonymously describing the order using the order data, send the notification to a first subset of the plurality of prospective parties and then the A notification generator configured to send the notification to a second subset of the plurality of prospective parties after a predetermined time has elapsed from the transmission of the notification to a first subset Anonymous block trading matching system comprising a. The method of claim 23, wherein And the predetermined time is 1 minute. The method of claim 23, wherein And a user must have utilized the system to perform a predetermined number of securities transactions in the past in order to qualify for inclusion in the first subset. The method of claim 25, The anonymous block transaction matching system, wherein the number of the security transaction is one. The method of claim 25, And the entitlement is a condition imposed on the user using the system within a predetermined past time. The method of claim 27, And the predetermined past time is one week. The method of claim 23, wherein And the notification generator is configured to send the notification, upon request of a new order. The method of claim 23, wherein And the notification generator is configured to send the notification according to the application of the firm order. A server configured to receive order data for a security order by a first user; A core database for storing the order data; A notification generator configured to send a notification to anonymously describe the order to at least a second user using the order data; And A client configured to display to the second user a bidirectional messaging interface providing a negotiation conversation between the first user and the second user, the bidirectional messaging interface communicating from at least one of the first user and the second user. Constrains to a finite set of phrases- Anonymous block trading matching system comprising a. The method of claim 31, wherein And the bidirectional messaging interface is configured to limit communications from both the first user and the second user to the limited set of phrases. The method of claim 31, wherein And the bidirectional messaging interface is configured to convert a keystroke by the first user into a negotiation phrase and send the negotiation phrase to the second user. The method of claim 31, wherein And the bidirectional messaging interface is configured to convert soft button presses or mouse clicks by the first user into negotiation phrases and to send the negotiation phrases to the second user. The method of claim 31, wherein When negotiation is made between the first user and the second user using the bidirectional messaging interface, the system generates a negotiation ID attached to the order data and places the order other than the first user and the second user. An anonymous block trade matching system configured to lock another party from trading. A server configured to receive order data for a security order, the order data consisting of an indication that a net price improvement will be provided to the liquidity provider who applied for the order; A core database for storing the order data; And Matching engine to find counterpart orders that match the security order Anonymous block trading matching system that includes. The method of claim 36, A notification generator configured to send a notification to the at least one prospective trading party anonymously describing the order using the order data. Anonymous block transaction matching system further comprising. A server configured to receive order data for a user's stock order; A core database for storing the order data; And A matching engine for finding an opponent's order that matches the security order, the matching engine configured to reject the user's order if the order does not meet the minimum size threshold specified in the security; Anonymous block trading matching system that includes. The method of claim 38, And the minimum transaction volume threshold includes liquidity of the security. The method of claim 38, And the minimum transaction volume threshold comprises a price level of the security. The method of claim 38, And the minimum transaction volume threshold comprises a share quantity of the security. The method of claim 38, And the minimum trading volume threshold comprises an average daily stock trading volume of the securities traded on an exchange. The method of claim 38, A notification generator configured to send a notification to the at least one prospective trading party anonymously describing the order using the order data Anonymous block transaction matching system further comprising.

Images