Source: http://www.google.co.uk/patents/US7565313
Timestamp: 2015-11-25 06:13:59
Document Index: 63430439

Matched Legal Cases: ['Application No. 60', 'Application No. 60', 'application No. 09', 'application No. 09', 'Application No. 60', 'Application No. 60', 'application No. 09']

Patent US7565313 - Method and system for managing distributed trading data - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inAdvanced Patent SearchPatentsIn a preferred embodiment, the invention comprises a computer-implemented system and method of managing market information across a network of data providers, comprising the steps of: (a) electronically receiving first data including confidential information regarding market participants in a first system...http://www.google.co.uk/patents/US7565313?utm_source=gb-gplus-sharePatent US7565313 - Method and system for managing distributed trading dataAdvanced Patent SearchPublication numberUS7565313 B2Publication typeGrantApplication numberUS 10/310,345Publication date21 Jul 2009Filing date5 Dec 2002Priority date5 Dec 2001Fee statusPaidAlso published asEP1504385A2, EP1504385A4, US7778919, US20040034591, US20090281954, US20100268605, WO2003048905A2, WO2003048905A3, WO2003048905A8Publication number10310345, 310345, US 7565313 B2, US 7565313B2, US-B2-7565313, US7565313 B2, US7565313B2InventorsHenri Waelbroeck, Fred J. Federspiel, John E. LopezOriginal AssigneePipeline Financial Group, Inc.Export CitationBiBTeX, EndNote, RefManPatent Citations (48), Non-Patent Citations (7), Referenced by (83), Classifications (17), Legal Events (5) External Links: USPTO, USPTO Assignment, EspacenetMethod and system for managing distributed trading data
US 7565313 B2Abstract
1. A computer-implemented method of managing market information across a network of data providers, comprising the steps of:
(a) electronically receiving first data including confidential trading interest information regarding market participants in a first system that protects said first data behind a firewall;
(b) electronically receiving second data including confidential trading interest information regarding market participants in a second system that protects said second data behind a firewall;
(c) electronically issuing an advertisement request message from said first system to said second system, said advertisement request message comprising display attributes of said confidential trading interest information from said first system;
(d) electronically prompting said second system via the advertisement request message to send a coordination request message to a Coordination Hub, said coordination request message comprising information deduced from said confidential trading interest information regarding market participants in said first and second systems;
(e) electronically prompting based on the coordination request message said Coordination Hub to issue permissions to advertise the display attributes of the confidential trading interest information from said first system to said second system; and
(f) electronically prompting said second system to display said display attributes of the confidential trading interest information from said first system based on the permissions to advertise.
2. A computer system for managing market information across a network of data providers, comprising:
(a) a first system for electronically receiving first data including confidential trading interest information regarding market participants, said first system protecting said first data behind a firewall;
(b) a second system for electronically receiving second data including confidential trading interest information regarding market participants, said second system protecting said second data behind a firewall;
said first system electronically issuing an advertisement request message to said second system, said advertisement request message comprising display attributes of said confidential trading interest information from said first system; and
(c) a Coordination Hub, said second system being prompted via the advertisement request message to send a coordination request message to said Coordination Hub, said coordination request message comprising information deduced from said confidential trading interest information regarding market participants in said first and second systems;
said Coordination Hub being electronically prompted based on the coordination request message to issue permissions to advertise the display attributes of the confidential trading interest information from said first system to said second system; and
said second system being electronically prompted to display said display attributes of the confidential trading interest information from said first system based on the permissions to advertise.
3. The method of claim 1, wherein said confidential trading interest information regarding market participants from a first system comprises an order.
4. The method of claim 1, wherein said confidential trading interest information regarding market participants from a first system comprises an indication of interest.
5. The method of claim 1, wherein said confidential trading interest information comprises targeting parameters.
6. The method of claim 1, wherein said confidential trading interest information comprises an advertisement request message.
7. The method of claim 1, wherein said display attributes comprise symbol.
8. The method of claim 1, wherein said display attributes comprise side.
9. The method of claim 1, wherein said display attributes comprise quantity.
10. The method of claim 1, wherein said display attributes comprise minimum quantity.
11. The method of claim 1, wherein said display attributes comprise advertisement request message duration.
12. The method of claim 1, wherein said display attributes comprise advertisement request message ID.
13. The method of claim 1, wherein said display attributes comprise current midpoint price of symbol.
14. The method of claim 5, wherein said targeting parameters further comprise an advertisement request message reason.
15. The method of claim 5, wherein said targeting parameters further comprise minimum requirements for issuing permissions to advertise the display attributes of the confidential trading interest information display.
16. The method of claim 1, wherein said deduction of information from said confidential trading interest information regarding market participants in said first and second systems comprises checking for appropriate advertisement request message reason.
17. The method of claim 1, wherein said deduction of information from said confidential trading interest information regarding market participants in said first and second systems comprises calculating an advertisement request message qualification score.
18. The method of claim 1, wherein said electronically prompting said second system via the advertisement request message to send a coordination request message to a Coordination Hub is based on said advertisement request message qualification score.
19. The method of claim 1, wherein multiple sets of said second data are aggregated.
20. The method of claim 19, wherein the market participants in the second system choose whether or not to enable aggregation of their sets of second data.
21. The method of claim 19, wherein the multiple sets of the second data are aggregated using an aggregation table.
22. The method of claim 21, wherein the aggregation table comprises a table of a plurality of character strings, each of the character strings being used by one of the participants in the second system to identify a client of said one of the participants in the second system.
23. The method of claim 19, wherein the multiple sets of second data are aggregated in the Coordination Hub.
24. The method of claim 23, wherein the Coordination Hub issues the permissions to advertise to each of the second systems from which the multiple sets of the second data are aggregated.
25. The method of claim 23, wherein the Coordination Hub issues the permissions to advertise to one of the second systems having a greatest number of items to be traded relating to the confidential trading interest information.
26. The method of claim 23, wherein the Coordination Hub issues the permissions to advertise to one of the second systems identified in the confidential trading interest information.
27. The method of claim 23, wherein the Coordination Hub issues the permissions to advertise to one of the second systems that has most recently traded items relating to the confidential trading interest information.
28. The method of claim 23, wherein the Coordination Hub issues the permissions to advertise to one of the second systems that is selected randomly.
29. The method of claim 23, wherein a plurality of rules are provided to determine to which of the second systems the Coordination Hub sends the permissions to advertise.
30. The method of claim 29, wherein the confidential trading interest information comprises a selection of one of the rules.
31. The method of claim 30, wherein the second systems determine whether or not to allow aggregation in response to the selection.
32. The method of claim 23, wherein a single rule is provided to determine to which of the second systems the Coordination Hub sends the permissions to advertise.
33. The method of claim 23, wherein the Coordination Hub issues the permissions to advertise in accordance with a highest matching priority among the sets of second data.
34. The method of claim 33, wherein the highest matching priority is determined from a price time priority rule.
35. The method of claim 33, wherein the highest matching priority is determined from a price size.
36. The method of claim 33, wherein the sets of second data include differing prices for differing order sizes, and wherein the highest matching priority is determined in accordance with the differing prices for the differing order sizes in the sets of second data.
37. The method of claim 1, wherein the advertisement request message is validated as corresponding to either a new indication of interest or a response to a previous indication of interest.
38. The method of claim 1, wherein an order may be placed in response to the display of said display attributes.
39. The method of claim 38, wherein, if the order cannot be filled with a specified condition, that order is sent as a sweep order.
40. The method of claim 38, wherein the order is divided into smaller orders.
41. The method of claim 40, wherein either the order or the smaller orders are advertised in accordance with market conditions.
42. The method of claim 40, wherein the order is divided into the smaller orders through an algorithm or algorithmic trading engine.
43. The method of claim 42, wherein the confidential trading interest information comprises an indication of a rate at which the order should be worked through the algorithm or algorithmic trading engine.
44. The method of claim 43, wherein, if the order is not filled at the rate indicated in the confidential trading interest information, the algorithm or algorithmic trading engine re-divides the order so as to accelerate execution of the order.
45. The method of claim 42, wherein the order is advertised simultaneously with an operation of the algorithm or algorithmic trading engine to process the smaller orders.
46. The method of claim 45, wherein, when a contra order is placed in response to the order, the smaller orders that are still open are pulled back as needed to fill the contra order.
47. The method of claim 46, wherein the confidential trading interest information comprises an indication of a rate at which the order should be worked through the algorithm or algorithmic trading engine.
48. The method of claim 47, wherein, if the order is not filled at the rate indicated in the confidential trading interest information, the algorithm or algorithmic trading engine re-divides the order so as to accelerate execution of the order.
49. The method of claim 1, wherein a counter-offer may be placed in response to the display of said display attributes.
50. The method of claim 1, wherein the confidential trading information from the first system comprises a price range in which an order is immediately executable.
51. The method of claim 1, wherein the confidential trading information from the first system further comprises a price range in which the order is negotiable.
52. The method of claim 51, wherein the price range in which the order is immediately executable comprises a first price range for a first order size range and a second price range for a second order size range.
53. The method of claim 1, wherein the first system does not receive any information in response to the confidential trading interest information until the second system has received a matching response order.
54. The method of claim 1, wherein the first system receives information in response to the confidential trading interest information, the information received in response comprising an indication of whether the confidential trading interest information successfully identified one or more targets in the second system.
55. The method of claim 54, wherein, when there are no such targets, the confidential trading interest information is declined.
56. The method of claim 54, wherein the information received in response further comprises an indication of whether said display attributes have been displayed.
57. The method of claim 56, wherein the information received in response further comprises an indication of a number of parties to whom the display attributes have been displayed.
58. The method of claim 57, wherein the indication of the number of parties is delayed.
59. The method of claim 1, wherein the display attributes are displayed only to parties who tend to act on the display attributes.
60. The method of claim 1, wherein the confidential trading interest information comprises an indication of a interest in selling a first item and buying a second item as part of a transaction.
61. The method of claim 60, wherein one of the selling and the buying is conditioned on the other of the selling and the buying.
62. The system of claim 2, wherein said confidential trading interest information regarding market participants from a first system comprises an order.
63. The system of claim 2, wherein said confidential trading interest information regarding market participants from a first system comprises an indication of interest.
64. The system of claim 2, wherein said confidential trading interest information comprises targeting parameters.
65. The system of claim 2, wherein said confidential trading interest information comprises an advertisement request message.
66. The system of claim 2, wherein said display attributes comprise symbol.
67. The system of claim 2, wherein said display attributes comprise side.
68. The system of claim 2, wherein said display attributes comprise quantity.
69. The system of claim 2, wherein said display attributes comprise minimum quantity.
70. The system of claim 2, wherein said display attributes comprise advertisement request message duration.
71. The system of claim 2, wherein said display attributes comprise advertisement request message ID.
72. The system of claim 2, wherein said display attributes comprise current midpoint price of symbol.
73. The system of claim 64, wherein said targeting parameters further comprise an advertisement request message reason.
74. The system of claim 64, wherein said targeting parameters further comprise minimum requirements for issuing permissions to advertise the display attributes of the confidential trading interest information display.
75. The system of claim 2, wherein said deduction of information from said confidential trading interest information regarding market participants in said first and second systems comprises checking for appropriate advertisement request message reason.
76. The system of claim 2, wherein said deduction of information from said confidential trading interest information regarding market participants in said first and second systems comprises calculating an advertisement request message qualification score.
77. The system of claim 2, wherein said electronically prompting said second system via the advertisement request message to send a coordination request message to a Coordination Hub is based on said advertisement request message qualification score.
78. The system of claim 2, wherein multiple sets of said second data are aggregated.
79. The system of claim 78, wherein the market participants in the second system choose whether or not to enable aggregation of their sets of second data.
80. The system of claim 78, wherein the multiple sets of the second data are aggregated using an aggregation table.
81. The system of claim 80, wherein the aggregation table comprises a table of a plurality of character strings, each of the character strings being used by one of the participants in the second system to identify a client of said one of the participants in the second system.
82. The system of claim 78, wherein the multiple sets of second data are aggregated in the Coordination Hub.
83. The system of claim 82, wherein the Coordination Hub issues the permissions to advertise to each of the second systems from which the multiple sets of the second data are aggregated.
84. The system of claim 82, wherein the Coordination Hub issues the permissions to advertise to one of the second systems having a greatest number of items to be traded relating to the confidential trading interest information.
85. The system of claim 82, wherein the Coordination Hub issues the permissions to advertise to one of the second systems identified in the confidential trading interest information.
86. The system of claim 82, wherein the Coordination Hub issues the permissions to advertise to one of the second systems that has most recently traded items relating to the confidential trading interest information.
87. The system of claim 82, wherein the Coordination Hub issues the permissions to advertise to one of the second systems that is selected randomly.
88. The system of claim 82 wherein a plurality of rules are provided to determine to which of the second systems the Coordination Hub sends the permissions to advertise.
89. The system of claim 88, wherein confidential trading interest information comprises a selection of one of the rules.
90. The system of claim 89, wherein the second systems determine whether or not to allow aggregation in response to the selection.
91. The system of claim 82, wherein a single rule is provided to determine to which of the second systems the Coordination Hub sends the permissions to advertise.
92. The system of claim 82, wherein the Coordination Hub issues the permissions to advertise in accordance with a highest matching priority among the sets of second data.
93. The system of claim 92, wherein the highest matching priority is determined from a price time priority rule.
94. The system of claim 92, wherein the highest matching priority is determined from a price size.
95. The system of claim 92, wherein the sets of second data include differing prices for differing order sizes, and wherein the highest matching priority is determined in accordance with the differing prices for the differing order sizes in the sets of second data.
96. The system of claim 2, wherein the advertisement request message is validated as corresponding to either a new indication of interest or a response to a previous indication of interest.
97. The system of claim 2, wherein an order may be placed in response to the display of said display attributes.
98. The system of claim 97, wherein, if the order cannot be filled with a specified condition, that order is sent as a sweep order.
99. The system of claim 97, wherein the order is divided into smaller orders.
100. The system of claim 99, wherein either the order or the smaller orders are advertised in accordance with market conditions.
101. The system of claim 97, wherein the order is divided into the smaller orders through an algorithm or algorithmic trading engine.
102. The system of claim 101, wherein the confidential trading interest information comprises an indication of a rate at which the order should be worked through the algorithm or algorithmic trading engine.
103. The system of claim 102, wherein, if the order is not filled at the rate indicated in the confidential trading interest information, the algorithm or algorithmic trading engine re-divides the order so as to accelerate execution of the order.
104. The method of claim 101, wherein the order is advertised simultaneously with an operation of the algorithm or algorithmic trading engine to process the smaller orders.
105. The method of claim 104, wherein, when a contra order is placed in response to the order, the smaller orders that are still open are pulled back as needed to fill the contra order.
106. The method of claim 105, wherein the confidential trading interest information comprises an indication of a rate at which the order should be worked through the algorithm or algorithmic trading engine.
107. The method of claim 106, wherein, if the order is not filled at the rate indicated in the confidential trading interest information, the algorithm or algorithmic trading engine re-divides the order so as to accelerate execution of the order.
108. The system of claim 2, wherein a counter-offer may be placed in response to the display of said display attributes.
109. The system of claim 2, wherein the confidential trading information from the first system comprises a price range in which an order is immediately executable.
110. The system of claim 2, wherein the confidential trading information from the first system further comprises a price range in which the order is negotiable.
111. The system of claim 110, wherein the price range in which the order is immediately executable comprises a first price range for a first order size range and a second price range for a second order size range.
112. The system of claim 2, wherein the first system does not receive any information in response to the confidential trading interest information until the second system has received a matching response order.
113. The system of claim 2, wherein the first system receives information in response to the confidential trading interest information, the information received in response comprising an indication of whether the confidential trading interest information successfully identified one or more targets in the second system.
114. The system of claim 113, wherein, when there are no such targets, the confidential trading interest information is declined.
115. The system of claim 113, wherein the information received in response further comprises an indication of whether said display attributes have been displayed.
116. The system of claim 115, wherein the information received in response further comprises an indication of a number of parties to whom the display attributes have been displayed.
117. The system of claim 116, wherein the indication of the number of parties is delayed.
118. The system of claim 2, wherein the display attributes are displayed only to parties who tend to act on the display attributes.
119. The system of claim 2, wherein the confidential trading interest information comprises an indication of a interest in selling a first item and buying a second item as part of a transaction.
120. The system of claim 119, wherein one of the selling and the buying is conditioned on the other of the selling and the buying.
121. An article of manufacture for managing market information across a network of data providers, the article of manufacture comprising:
This application claims priority to U.S. Provisional Application No. 60/336,775, filed Dec. 5, 2001, and U.S. Provisional Application No. 60/400,467, filed Aug. 1, 2002. The entire contents of each application are incorporated herein by reference.
In a co-pending application, U.S. patent application No. 09/870,849, “A Method for Directing and Executing Certified Trading Interests,” filed May 31, 2001 (the entire contents of which are incorporated herein by reference for all purposes), a system is described for using confidential market data to route information about new live, confidential orders specifically to likely contras, based on certified trading interest information such as the trades a possible target has recently executed. This system is particularly well-suited when data is naturally aggregated at a particular market center, as is the case for members of a stock market or an exchange, known as “sell-side” firms.
SUMMARY OF THE INVENTION The present invention implements a search for counter-parties across a plurality of data providers. In the preferred embodiment the system comprises a matching engine or auction server and a plurality of network-connected computer systems, called “routing engines”, and/or interfaces to remote databases, collectively called “data providers.” A search is initiated when a first participant enters an order to buy or sell a given security into the matching engine or auction server, and requests that this order be advertised to counter-parties that have expressed a trading interest on the contra side. The system preferably defines a protocol for specifying such advertisement requests with a few parameters; for example, the first participant will type the characters “B2” in a text message field to indicate that the order should be advertised to the two buy-side firms that have most recently traded 10,000 shares net on the contra side in the given security. If the first participant does not specify such parameters, the system preferably inserts default advertisement parameters.
A search for counter-parties is preferably implemented in a manner that provides benefits to each participating data provider as well as to end parties that receive information about orders. The search preferably is based on two principles: the first is that the end target's information is used only to determine when it should receive information about a new order. The second is that the interests of a party that provides data are protected. This second principle preferably is implemented by enabling data providers to elect to participate in one of two possible ways. The first type of data provider will keep its data behind a firewall and allow access to said data on an “as needed” basis—only for the purpose of executing a specific type of query request, and only when said query request is directly related to a revenue-generating opportunity, such as the possibility of facilitating a successful trade or of being party to such a trade. For example, the query may be requested for the purpose of advertising a live, electronically-executable order, and return only the identity of the firm that has most recently bought at least 10000 shares, the time interval during which this accumulation has taken place, and the list of fills that the firm has received on both sides of the security in said time interval. The system preferably provides an Applications Programming Interface (API) that allows data participants of this type to develop their own software application that will work behind their firewall and process the query requests. The data returned in response to a query may be stored together with similar data from other data providers for the purpose of executing a query to implement the first participant's instructions on how to find likely contra parties—for example, by identifying the two firms that have most recently accumulated 10,000 shares. The second type of data provider also keeps their trade data behind a firewall and further elects to keep the identity of the end client permanently masked from the matching engine or auction server issuing the query request. For example, it may be a broker with an established sales channel to the end user. This second type of data provider hosts a subsystem, referred to herein as a “routing engine,” that resides behind a firewall and protects the confidentially of the data it accesses by intermediating subsequent communications between the matching engine or auction server and the end client.
The system preferably enables a first participant entering an order to request a search for likely contras by combining the results of queries at a plurality of databases to produce a distribution list for displaying said first participant's order. When all data providers allow the identity of the end client to be returned, the requesting system preferably asks for and receives all the data that is required to compute said distribution list. When one or more data providers do not wish to disclose the identity of the client that satisfies the query parameters, but instead host a routing engine that will intermediate further communications with their client, each such routing engine will preferably determine based upon the query type whether or not a given target must be validated by combining data across the whole network of databases using a central Coordination Hub service. For example, a first participant request to advertise the order to the two firms that have sold the largest net amount of the given stock in the current trading day requires validation since a single routing engine cannot know if its ranks among the top two firms across the network. If targets must be validated across the network, each routing engine will report to said Coordination Hub, providing only the minimal information that is required to determine the rank of its targets in the distribution list. An example of a query request that does not require validation across a plurality of databases is one where the first participant has requested that the order be shown to the party that took part in a prior trade between the same two parties. The matching engine receives the first participant's order, and asks the routing engine that was involved in the prior trade to notify its client that this new order is available. Another example of a query type that requires validation is one mentioned previously where the first participant has requested that the order be displayed to the two parties that have most recently accumulated 10,000 shares on the contra side. In this example, each routing engine will return the timestamps of the targets that have to its knowledge most recently traded 10,000 shares net, but will not disclose the identities of the parties. The Coordination Hub determines which two proposed targets win the contest for “most recently” accumulating 10,000 shares, and responds to each routing engine with a message authorizing that routing engine to display the first participant's order only to its winning target(s).
Once the contra parties have been identified, the preferred auction server or matching engine issues a message containing information about the first participant's order as instructed by order display attributes attached to the first participant's order. The message is routed to a second participant and possibly others as determined by the advertising instructions in the first participant's order, through any routing engines that may have facilitated the process of discovering the identity of the second participant. The second participant preferably is enabled to enter a response order, which is then routed back to the matching engine or auction server through the same channel that delivered the IOI message to said second participant. The auction server or matching engine then preferably matches and executes orders as instructed by the order attributes and reports the trade status back to the first and second participants. For example, in a call auction the first participant order contains the time of the call, which is displayed to the second participant through the IOI message. The second participant's order is stored in an auction book, and at the time of the auction call, all orders received are matched using the auction's rules. For example, the auction match can be a Dutch auction, as is known in the art. In another example, the orders are placed in a matching engine that checks all orders on arrival to see if they match with a previously entered order, and if so executes the corresponding trades; in this embodiment orders are processed on a first come first served basis. Other examples of matching engine or auction server designs will be comprehended by those skilled in the art, and/or are described in co-pending U.S. patent application No. 09/870,849.
The system preferably enables the optional aggregation of data from a plurality of routing engines. If a routing engine opts to allow the Coordination Hub to aggregate its data with data from other (perhaps similar) routing engines, it requests a key from the trusted key provider named in the query request message and identifies its clients to the Coordination Hub using this key. The key is used to mask the true identity of the proposed targets to the Hub, while at the same time enabling the Coordination Hub to determine when potential targets being proposed by two different query engines are in fact one and the same. In query requests with aggregation, each participating routing engine preferably reports detailed data to the Coordination Hub, so the Hub can combine data from multiple data providers to determine the best targets. For example the data reported may be a list of fills pertaining to Institutions that are alleged to be likely contras for the first participant's order, and the Hub ranking is performed based upon a query in an aggregate table where fills from the same Institution may have been entered by a plurality of routing engines. The ability to anonymously aggregate trading interest information from multiple sources helps to avoid potential misuse of the system by unscrupulous parties who might indicate a buy interest in one place and compensate with a sell interest in another, effectively combining the two to attract information about orders on both sides. Due to this potential gaming problem, and also due to the fact that large buy-side institutions spread their trading data across a plurality of brokers that stand to participate as data providers in the present system, there is clearly multiplicative value in being able to aggregate buy-side trading interest information across a plurality of databases. Large brokers such as Goldman Sachs use this to their advantage through the work of their sales desk, maximizing internalization rates. ECNs in effect face the same situation when they seek to achieve “critical mass.” For example, Instinet is able to charge a greater fee for accessing the liquidity on its book because of its depth of institutional liquidity.
In the business of finding a contra for a large order, this points to a potential for creating a “natural monopoly” in brokerage data management, if this can be conceived as a service to all. The DTCC, for example, has the required data to perform such a function. It has not done so, presumably because its business model precludes using its position as data aggregator to compete with its members.
The system and methods described herein provide alternatives to existing systems by creating what could be termed a “federated data management system,” where no central party controls the system and every member can decide whether to enable aggregation based on the case at hand.
This federated data management system with aggregation preferably is based on the following principles:
1) Protecting data providers. When the subject system uses data provided by parties that wish to keep the identity of the end clients confidential, said system enables all communications between the system and the end client to be routed through the data provider's own communication channels to the end client. 2) Client confidentiality in aggregation. Buy-side clients may only permit their trade data to be aggregated if the party that performs the aggregation cannot discover the identity of the client. In a preferred embodiment, a client ID used for aggregation is incomprehensible to the party performing the aggregation and is used only once (“fire and forget”). 3) Protection from collusion. Each participant can decide whether to permit anonymous aggregation based on the identity of two parties: the party performing the aggregation, and the party who provides the aggregation key. The participant will determine whether it is confident that these two parties will not violate the confidentiality of the aggregation key. 4) Voluntary aggregation. Each participant can decide whether to permit anonymous aggregation based on the message type (to be delivered to the winning client), and query type. For example, a query seeking the largest institutional seller of a given security during a whole month may be considered unacceptable, since it risks indirectly revealing the identity of the targets through a comparison with the quarterly filings of known buy-side Institutions. The same query with a 15-minute time window would present no such risks. If a party does not enable aggregation, it will participate in the system based solely on its own data. 5) Multiple data providers for the same target. When a client wins a query based on data aggregated from multiple data providers, configurable rules determine how the revenue from a subsequent trade is to be shared with the data providers. For example, the revenue can go exclusively to the party that provided the most recent data entry, or it can be shared among data contributors in proportion to the volume of data they contributed to the aggregation. Data providers can elect to accept or reject the aggregation request based upon the choice of rule. In a preferred embodiment, the invention comprises a computer-implemented system and method of managing market information across a network of data providers, comprising the steps of: (a) electronically receiving first data including confidential information regarding market participants in a first system that protects said first data behind a firewall; (b) electronically receiving second data including confidential information regarding market participants in a second system that protects said second data behind a firewall; (c) electronically receiving an order and targeting parameters from a first market participant; (d) electronically issuing an advertisement request message to said first system and said second system, said advertisement message comprising display attributes of said order and comprising said targeting parameters; (e) electronically prompting said first system and said second system via the advertisement request message to each send a coordination request message to a Coordination Hub, said coordination request message comprising information deduced from said confidential information regarding market participants in said first and second systems, wherein the selection of the information that is sent to the Coordination Hub is based at least in part on said first market participant's targeting parameters; (f) electronically prompting based on the coordination request message said Coordination Hub to issue permissions to advertise the order to selected market participants, wherein market participants are selected based, at least in part, on said received information regarding market participants; and (g) electronically prompting based on the permissions to advertise the order said first system and said second system to route information about said order from first participant to said selected market participants.
BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1A depicts network architecture for an embodiment that comprises several routing engines.
FIG. 1B gives an example of a network configuration that was described in U.S. Provisional Application No. 60/336,775.
FIG. 2 illustrates operation of a preferred matching engine.
FIG. 3 illustrates operation of a preferred routing engine.
FIG. 4 depicts a preferred New Order form.
FIG. 5 depicts a preferred Targeting form.
FIG. 6 depicts flow corresponding to a successfully completed trade.
Definitions A “client” is an individual or entity that will receive targeted messages. An “implementation” is a single deployment of the disclosed distributed computer system, connected to a communication network. A “participant” is an individual or entity that agrees to host an implementation of said distributed computer system. The “score” of a client is a real number that represents the net value of showing information to this client, considering the positive contribution from the likelihood that the order will be filled and subtracting the negative contribution from the risks associated with information leak. A “score evaluation function” is an algorithm for determining a client score from data that is contributed by one or more data providers.
A preferred embodiment of the present invention comprises a system that lets a first participant (the “initiator”): (1) enter an order to buy or sell a fungible item such as a publicly traded security into a matching engine or auction server; (2) request that the system create a distribution list to contain “likely counter-parties,” based on specific criteria, which preferably entail executing a distributed query across a plurality of databases; and (3) request that the system display information about the order (which may include the security, the side, the quantity or a less quantity, and/or the limit price or a less aggressive displayed price) to the members of the distribution list.
The initiating participant (“initiator”) typically does not know the identity of the client(s) that are to receive the messages. Therefore, communications with this client are routed through the party that provided data on the client. In this way, data providers intermediate communications between initiator and client.
Alternatively, the data-providing party can be the client itself, and an anonymizing intermediary (a “router”) can be used to mask the client's identity. For the purposes of this description, we will consider the router to be the “data provider,” since it effectively has access to the clients' data and intermediates all communications between the initiator and clients.
Each implementation of the system preferably enables an operator to configure how the system should respond to queries based on the message type that is to be delivered. Preferred options are: (a) do not respond; (b) respond but do not permit aggregation; or (c) respond and permit aggregation. The message type preferably is specified by the data query that is to be executed, the identity of the aggregation key provider and the aggregating party, and the rule for sharing revenue when multiple data providers are involved in selecting a client for a transaction.
Aggregation preferably is performed according to a table (see exemplary Tables A1-A4 below.) that comprises one row per client known in the system (union set of the clients known to at least one participant) and a column for each party that submits data for aggregation.
In the example shown in Tables A1-A4, Table A1 shows the full aggregation table, which is known to the key provider only. Table A2 shows the information that is known to a Coordination Hub that is enabled to aggregate data, when said Hub is hosted by a neutral party, i.e. one that does not also host a routing engine. Table A3 gives an example of the information that is known to routing engine A and used to issue keys to describe its clients to the Coordination Hub. Table A4 shows the aggregation table known to a Coordination Hub that is hosted by the same firm that also operates routing engine C; column C is removed from the table since it would reveal the client identities known to this routing engine, and the lines are reordered at random. Routing engine C will also have a table similar to Table A3 for use when aggregation is to be performed through another Coordination Hub.
The primary case of interest is one where N participants possess quantitative data concerning clients enabling the evaluation of the clients' scores. No participant typically is willing to share the data about named clients with the other parties, but each participant will permit the aggregation of their client's data with other participants when this improves its chance of being selected to intermediate a transaction involving the client. A line in the aggregation table gives the ID (a character-string) that each participant will use to identify a client. The aggregator will receive messages from a plurality of participants comprising information on clients. It aggregates information on a client when it finds that the client-ID associated with the information reported by one participant is in the same line of the aggregation table as the client-ID associated with information reported by another participant.
Routing Engine A
Routing Engine B
Routing Engine C
123-dfg-543
Sdfl-w34-45
Gjw-239-sdj
3834-fh-387
Askdf-2134-wsfe
Sdfkh-234
Asfh-283-345
We-234-ert
Asdhf-234-gdf
Sdfk-23k-sdf
Sdf-234-sd
Sdkf-234-sdf
Sdkfh-234
TAII Cref
The aggregation table itself is preferably created by a central trusted key provider that maintains a list of clients based on a globally recognized name for each client and creates a unique client-ID string per client for each participant. A participant that wishes to be a data aggregator may request an aggregation table that will contain the client-IDs known to other participants but will not contain the client-IDs known to itself, so a participant can be an aggregator for all but its own data without being able to infer the identity of the clients involved in the aggregation.
In an alternate embodiment, there are no aggregation tables but the central key provider provides all routing engines that participate in aggregation with an encryption key. The routing engines use this key to encrypt the globally recognized name of the client's firm—for example, using the firm naming convention of a third party such as Bloomberg or Reuters. Since the Coordination Hub does not know the matching key, it is not able to decrypt the client ID to determine the true identity of the client firm—it simply sees the same client-ID (same character string with no obvious meaning) when two routing engines provide data that pertains to the same client, thereby enabling aggregation of the data.
In a preferred embodiment, the system comprises one or more matching engines, or an interface to a third party matching engine, such as a FIX interface to an ECN, and a plurality of routing engines. (The Financial Information eXchange (FIX) protocol is a messaging standard developed specifically for the real-time electronic exchange of securities transactions.) Each routing engine utilizes one or more query engines that will access local and/or remote databases to execute a database query, with the same effect as if all the data were held locally. When accessing remote databases it preferably will receive in response only the information that is needed to evaluate the proposed target's quality as a likely contra for the first participant's order. This enables each data provider to determine, based on the type of query and the purpose of the query, whether or not to provide access to its data. For example, a data provider may provide access only when needed for the purpose of facilitating a successful trade, and only for a query that will return the sequences of trades done by firm(s) that have led to a recent accumulation of 10,000 shares net on either the buy or sell side in a given security. The preferred system effectively inserts the results of an externalized query in its local database when the external data provider accepts the request, or proceeds without the benefit of said external data when said data provider refuses the request or has no relevant data to offer. The system preferably stores information that includes the parties that provided data that helped to find a counter party for the first participant's order and the specific data provided by said parties, and makes that information available to a billing system for the purpose of providing payments to data providers when their data helps to facilitate successful trades.
Each routing engine preferably connects to one or more auction servers or matching engines. When the routing engine is configured to connect to a single matching engine or auction server, it receives requests to advertise an order from this single auction server or matching engine, routes IOIs to the targeted second participants as described herein, and routes subsequent transactions back and forth between the matching engine or auction server and said second participant(s). When the routing engine is configured to connect to a plurality of auction servers or matching engines, it processes requests from any auction server or matching engine and routes subsequent related trade messages back and forth between the second participant(s) and the auction server or matching engine that entered the corresponding request. In embodiments that enable aggregation of data from multiple routing engines, each routing engine connects to one or more aggregation key providers. When there are more than one participating key providers, a request to advertise an order through aggregate data queries preferably carries the name of the key provider that should be used, or a global default key provider that is common to all routing engines. In an alternate embodiment, each routing engine chooses a key provider and aggregation is enabled only by groups of routing engines that choose the same key provider. In embodiments that support requests where a Coordination Hub must decide the winning target from those proposed by a plurality of routing engines, the routing engine also connects to one or more Coordination Hubs. A request to advertise an order through aggregate data queries must carry the ID of the Coordination Hub that should be used, or a global default Coordination Hub for this type of request that is common to all routing engines. For example, one Coordination Hub may provide services for ranking targets based on trade information, while another Coordination Hub may rank targets based on data on unfilled orders.
The network configuration in a preferred embodiment is a star network with multiple star centers, one for each matching engine, one for each key provider, and one for each coordination hub. Each star center is connected to a plurality of routing engines; the routing engines are the rays that extend from the star's center. As shown in FIG. 1, the routing engines in turn are connected to one or more and clients through a communications network such as a FIX network. FIG. 1A shows the network architecture for a general embodiment that comprises several routing engines, each of which can be connected to a plurality of matching engines, and can coordinate their communications with the Coordination Hub using an aggregation key provided by a Key Provider. FIG. 1B gives an example of a network configuration that was described in U.S. Provisional Application No. 60/336,775, comprising two Matching Engines (being Nasdaq's Liquidity Tracker trading facility and one other Matching Engine), a single Coordination Hub and three Routing Engines, each of which is connected to the Hub and to both Matching Engines. The end clients are not shown in FIG. 1B.
A preferred embodiment of the invention is described below in a configuration that comprises a single matching engine, a coordination hub, and an aggregation key provider. Other configurations are extensions of this one wherein the software enables an operator to specify which matching engines a given routing engine connects to, which coordinated services it supports, and what key providers are enabled. A system with multiple services preferably rely on the method known in the art as data-driven routing, which enables an operator to configure routing tables and associated routing logic to specify where a message should be routed based on the routing table and the content of the message. For example, orders in Nasdaq-listed symbols may be routed to Nasdaq's Liquidity Tracker facility whereas orders in securities listed on the New York Stock Exchange would be routed to an alternate Matching Engine.
A preferred matching engine, such as the matching book of an Electronic Communications Network (ECN) or an auction server such as in U.S. patent application No. 09/870,840, receives an initiation order from a first participant and initiates a multiparty search wherein each routing engine that connects to this matching engine is invited to advertise the first participant's order to participants that have demonstrated a firm, verifiable interest in taking the contra side to said first participant's order. A preferred routing engine receives requests to advertise an order and places them in a queue for processing. Upon processing a request to advertise, a routing engine can search for a good contra based on its own data and the responses from queries into the databases participating external data providers, which can be implemented over a virtual private network (VPN), or forward the invitation to advertise said first participant's order anonymously to a configurable list of other routing engines. Each such rotating engine preferably applies similar processing, either advertising the order or anonymously forwarding the message to other routing engines. Requests to advertise a first participant's order preferably carry a unique order identifier (such as a Globally Unique Identifier, (“GUID”)) that is generated by the matching engine and preserved throughout the chain. To avoid redundant processing, each routing engine reads requests to advertise an order off a single input queue and acts only on the first message it receives that contains a given GUID. It disregards redundant copies of the same request that may have arrived through other paths.
Preferably, the initiation order contains routing and display instructions. The matching engine or auction server broadcasts an IOI to all routing engines that subscribe directly to it, together with the routing and display instructions. In one embodiment, the IOI is a FIX IOI and any routing and display instructions are placed in the text message field. Table C below gives an example of a compression mechanism to encode structured query instructions in a short text message field. An alternate embodiment uses a proprietary protocol over a dedicated TCP-IP connection to deliver IOIs with routing instructions. Yet another embodiment uses the Extended Markup Language (XML) to enable an extensible language of routing attributes. Other communication protocols will be recognized as appropriate by those skilled in the art.
The text message in a new order message as described herein can be used to carry optional order display attributes that are not supported by standard industry protocols such as FIX or internal order delivery protocols such as CTCI (Computer To Computer Interface) protocols. For example, the instructions on how to execute a database query to select targets to advertise an order are not supported in such protocols, because their designers did not anticipate the present invention.
In an alternate embodiment, the optional order display instructions are encoded using the