US20180336632A1 - System and Method for Providing Market Data in an Electronic Trading Environment - Google Patents
System and Method for Providing Market Data in an Electronic Trading Environment Download PDFInfo
- Publication number
- US20180336632A1 US20180336632A1 US16/046,415 US201816046415A US2018336632A1 US 20180336632 A1 US20180336632 A1 US 20180336632A1 US 201816046415 A US201816046415 A US 201816046415A US 2018336632 A1 US2018336632 A1 US 2018336632A1
- Authority
- US
- United States
- Prior art keywords
- price
- computing device
- tradeable object
- parameter
- sub
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/06—Asset management; Financial planning or analysis
Definitions
- the present invention is directed to electronic trading. More specifically, the present invention is directed towards providing market data in an electronic trading environment.
- Trading methods have evolved from an exclusively manual process to a technology enabled, electronic platform. With the advent of electronic trading, a user or trader can be in virtually direct contact with the market, from practically anywhere in the world, performing near real-time transactions, and without the need to make personal contact with a broker.
- traders are connected to an exchange's electronic trading platform by way of a communication link and through an application program interface to facilitate real-time electronic messaging between themselves and the exchange.
- the electronic trading platform includes at least one electronic market, which is the heart of the trading system for a particular tradeable object and handles matching of bids and offers placed by the subscribing traders for that tradeable object.
- the electronic messaging includes market information that is sent from the electronic exchange to the traders. Once the traders receive market information, it may be displayed to them on their trading screens. Upon viewing the information, traders can take certain actions, including the actions of sending buy or sell orders to the electronic exchange, adjusting existing orders, deleting orders, or otherwise managing orders. Traders may also use software tools on their client devices to automate these and additional actions.
- an electronic exchange can list any number of tradeable objects. Often times, traders will trade simultaneously more than one tradeable object, and they may trade simultaneously tradeable objects that are listed at more than one exchange.
- tradeable object refers to anything that can be traded with a quantity and/or price. It includes, but is not limited to, all types of traded events, goods and/or financial products, which can include, for example, stocks, options, bonds, futures, currency, and warrants, as well as funds, derivatives and collections of the foregoing, and all types of commodities, such as grains, energy, and metals.
- the tradeable object may be “real,” such as products that are listed by an exchange for trading, or “synthetic,” such as a combination of real products that is created by the user.
- a tradeable object could actually be a combination of other tradeable objects, such as a class of tradeable objects.
- each tradeable object has its own independent electronic market, and therefore, its own separate stream of market data, commonly referred to as a data feed.
- a data feed includes market information corresponding to a tradeable object, and the content of the data feed typically depends on the host exchange and on the tradeable object.
- Market information in a data feed commonly includes information related to the inside market and market depth.
- the inside market represents the lowest sell price (also referred to as the best or lowest ask price), and the highest buy price (also, referred to as the best or highest bid price).
- market depth includes quantities available for trading the tradeable object at certain buy and sell price levels away from the inside market. The extent of market depth available for a trader usually depends on the exchange.
- exchanges provide market depth for an infinite number of price levels, while some provide only quantities associated with the inside market, and others may provide no market depth at all. Additionally, exchanges can offer other types of market information in the data feeds, such as the last traded price (LTP), the last traded quantity (LTQ), and order fill information.
- LTP last traded price
- LTQ last traded quantity
- order fill information such as the last traded price (LTP), the last traded quantity (LTQ), and order fill information.
- each tradeable object is actually associated with its own separate stream of market information, in the instances when a trader trades more than one tradeable object, the trader will receive more than one data feed.
- traders might subscribe to news feeds, real-time quotation vendors that provide information to traders for decision support, and other information sources.
- a trader can link to host exchanges through one or more networks.
- a network is a group of two or more computers or devices linked together, and characterized by topology, protocol, and architecture. For example, some traders may link to the host through a direct network connection, such as a T1 or ISDN. Others may link to the host exchange through direct network connections, and through other common network components, such as high speed servers, routers, and gateways.
- the Internet a well-known collection of networks and gateways, can be used to establish a connection between the client device and the host exchange. There are many different types of wired and wireless networks and combinations of network types known in the art that can link traders to the host exchange.
- FIG. 1 is a block diagram illustrating an example network configuration that can be used to access one or more electronic exchanges
- FIG. 2 is a block diagram illustrating an example system that can be used for market data compression according to one example embodiment
- FIG. 3 is a block diagram illustrating an example probability model that can be defined in relation to a tradeable object
- FIG. 4 is a block diagram illustrating two market depth snapshots corresponding to a tradeable object at two consecutive times
- FIG. 5 is a message flow diagram illustrating an example method for providing market data to a client entity using data encoding based on probability models
- FIG. 6 is a block diagram illustrating an updated probability model of FIG. 4 based on market data changes illustrated in FIG. 5 ;
- FIG. 7 is a flowchart illustrating an example method for encoding market data according to one example embodiment.
- FIG. 8 is a flowchart illustrating an example method for decoding market data according to one example embodiment.
- the example embodiments are directed to providing market data to client devices.
- Typical market data consists of a collection of prices and quantities corresponding to a tradeable object.
- the market at any instant is likely to be quite similar to the market in the previous instant, with the change being often zero. If the market moves, it often changes by +/ ⁇ 1 tick.
- a sending entity such as an electronic exchange, or yet some other entity in communication with the exchange, may include a probability modeler that dynamically develops a probability model for a tradeable object.
- the probability model can be developed and dynamically updated based on market data being encoded and sent to a receiving entity, such as a client entity, over the network from the electronic exchange.
- the probability model for a tradeable object may include a plurality of probability values corresponding to many different market data parameters.
- the probability model may include a probability for detecting a change of +1 tick in relation to the best bid price in the market corresponding to the tradeable object.
- the probability values in the model corresponding to the change in the best bid price may be determined based on how many times a change of +1 tick has been encoded in relation to the best bid price during a certain time period in the past.
- the statistical compressions methods can then use the developed probability model to generate a compressed bit stream representing the change in best bid price, as well as other market data changes, corresponding to the tradeable object.
- the compressed bit stream may then be sent over one or more networks to the client entity.
- a receiving entity also includes probability models that are used to decode received compressed bit streams.
- the probability model that was used at the time of encoding a change in a certain market parameter is the same as the one that is used at the receiving entity at the time of decoding the change.
- the models can be updated after encoding and decoding the change corresponding to the market parameter. More details related to market data compression using probability models will be described below.
- the example embodiments may be operated in an entirely software embodiment, in an entirely hardware embodiment, or in a combination thereof.
- the example embodiments are described in a software-based embodiment, which is executed on a computer device.
- the example embodiments take the form of a computer program product that is stored on a computer readable storage medium and is executed by a suitable instruction system in the computer device.
- Any suitable computer readable medium may be utilized including hard disks, CD-ROMs, optical storage devices, or magnetic storage devices, for example.
- market data 108 in the form of messages, may be relayed from a host exchange 106 over communication links 116 and 112 to a client entity generally indicated as 102 .
- the client entity 102 may be a single client terminal that is used by a single trader or multiple client terminals corresponding to multiple traders associated with one or more trading groups.
- the client entity 102 may include any computer that accesses one or more networks.
- the client entity 102 can be a personal computer, a laptop computer, a hand-held device, and so on.
- intermediate devices such as gateway(s) 104 , may be used to facilitate communications between the client entity 102 and the host exchange 106 .
- gateway(s) 104 may be used to facilitate communications between the client entity 102 and the host exchange 106 .
- FIG. 1 illustrates the client entity 102 communicating with a single host exchange 106
- the client entity 102 could establish trading sessions to more than one host exchange.
- information being communicated to and from the client entity 102 and the exchange 106 could be communicated via a single communication path.
- the market data 108 contains information that characterizes the tradeable objects, including, among other parameters, order related parameters, such as price and quantity, and the inside market, which represents the lowest sell price (also referred to as the best or lowest ask price), and the highest buy price (also referred to as the best or highest bid price).
- market data may also include market depth, which generally refers to quantities available for trading the tradeable object at certain buy price levels and quantities available for trading the tradeable object at certain sell price levels.
- electronic exchanges can offer different types of market information such as total traded quantity for each price level, opening price, last traded price, last traded quantity, closing price, or order fill information. It should be understood that market information provided from an electronic exchange could include more or fewer items depending on the type of tradeable object or the type of exchange. Also, it should be understood that the messages provided in the market data 108 may vary in size depending on the content carried by them, and the software at the receiving end may be programmed to understand the messages and to act out certain operations.
- a trader may view the information provided from an exchange via one or more specialized trading screens created by software running on the client entity 102 .
- a trader may wish to take actions, such as send orders to an exchange, cancel orders at the exchange, or change order parameters, for example.
- the trader may input various commands or signals into the client entity 102 .
- the client entity 102 may generate messages that reflect the actions taken, generally shown at 110 . It should be understood that different types of messages or order types can be submitted to the host exchange 106 , all of which may be considered various types of transaction information.
- user action messages 110 may be sent from the client entity 102 to the host exchange over communication links 114 and 116 .
- the client entity 102 may use software that creates specialized interactive trading screens on the client entity 102 .
- the trading screens enable traders to enter and execute orders, obtain market quotes, and monitor positions.
- the range and quality of features available to the trader on his or her screens varies according to the specific software application being run.
- the client entity 102 may run automated non-interactive types of trading applications.
- X_TRADER® A commercially available trading application that allows a user to trade in systems like those shown in FIG. 1 and subsequent figures is X_TRADER® from Trading Technologies International, Inc. of Chicago, Ill.
- X_TRADER® also provides an electronic trading interface, referred to as MD TraderTM, in which working orders and bid/ask quantities are displayed in association with a static price axis or scale.
- MD TraderTM an electronic trading interface
- the scope of the example embodiments described herein are not limited by the type of terminal or device used, and are not limited to any particular type of trading application.
- Portions of the X_TRADER® and the MD TraderTM-style display are described in U.S. Pat. No. 6,772,132 entitled “Click Based Trading With Intuitive Grid Display of Market Depth,” filed on Jun.
- FIG. 2 is a block diagram illustrating an example system 200 that can be used for market data compression according to one example embodiment.
- the example system 200 illustrates a client entity 202 and an electronic exchange 204 communicating via a network 222 .
- the electronic exchange 204 uses statistical compression techniques to compress market data that is provided to the client entity 202 .
- FIG. 2 shows only certain elements of the exchange 204 and client entity 202 that can be used in relation to data compression/decompression, it should be understood that a typical exchange and a client entity may include many additional elements, such as interfaces, processors, and applications, that can be used for receiving and processing data being communicated between the exchange 204 and the client entity 202 . Also, it should be understood that while FIG.
- FIG. 2 illustrates a single network 222 that is used for sending data between the client entity 202 and the electronic exchange 204 , the two entities could communicate via multiple networks and additional intermediate devices, such as gateways, routers, or yet some other network devices. Additionally, while the compression elements are illustrated as being part of the exchange 204 , alternatively, these elements could be located on some other network entity in communication with the electronic exchange 204 .
- the electronic exchange 204 includes a compressor system 206 .
- the compressor system in turn includes a controller 208 , a probability modeler 210 , and an encoder 214 .
- the client entity 102 includes a decompressor system 216 with a controller 218 , a probability modeler 220 , and a decoder 224 .
- the compressor system 206 can use one or more compression algorithms that are to compress market data using statistical probability data according to the embodiments that will be described in greater detail below.
- the decompressor system 216 can use one or more decompression algorithms along with the statistical probability data to decompress any compressed data received from the electronic exchange 202 .
- ⁇ log 2 (p(S)) ⁇ log 2 (p(S))
- the probability of occurrence of a symbol if the probability of occurrence of a symbol is 0.25, the symbol could be represented with ⁇ log 2 (0.25) bits, or 2 bits.
- the number of bits that can be used to represent a symbol does not necessarily have to be represented with integer numbers.
- the number of bits could be represented with decimal numbers as well. For example, if a symbol is predicted with probability of 0.9, it would be represented with ⁇ log 2 (0.9) bits, or approximately 0.152 bits.
- the above equation would take a format of ⁇ log 2 (Tradeable Object Parameter Probabability).
- the probability modelers 210 and 220 generate market data probability models 212 and 222 .
- the compressor system 206 uses the probability models 212 to compress and encode market data and generate a compressed data stream to be sent to the client entity 202 .
- the probability models 222 can be used at the client entity 202 to decode and decompress received compressed data stream.
- the probability models include statistical data representing the probabilities of detecting a change in relation to certain parameters associated with market data, the examples of which will be described in relation to subsequent figures.
- the probability models could be dynamic or static.
- the example embodiments hereinafter describe probability models that are dynamically generated and updated during a trading day based on a frequency or history of changes in relation to certain parameters that the modeler has already seen.
- the probability model for symbols A, B, and C that has seen the sequence of symbols ABACAABC where, for example, the symbols correspond to changes detected in relation to three market levels
- the probability modelers 210 and 220 could predict that the probability that the next symbol will be A is 4/8 or 0.5, and B and C would be predicted with the probability of 2/8 or 0.25.
- each tradeable object could be associated with its own probability model.
- FIG. 2 shows a plurality of probability models created for a plurality of tradeable objects, “TO 1” through “TO X.”
- Each tradeable object probability model may in turn include a number of probability sub-models.
- a probability sub-model may define probability levels for one or more market data parameters associated with the tradeable object.
- typical market data that will be compressed consists of a collection of prices and quantities corresponding to a tradeable object.
- For each tradeable object there are two sides of market depth, a bid side and an ask side, along with a variety of different parameters, such as a last traded price and a last traded quantity.
- the market depth may include a preset number of levels ranging from only the inside market to an unlimited number of levels. While the number of market depth levels that will be compressed may be equal to the number of market depth levels typically provided by the exchange, fewer market depth levels could be compressed as well.
- FIG. 3 is a block diagram illustrating an example probability model 300 that can be defined in relation to a tradeable object.
- the probability model 300 includes a “Parameter” field 302 , a “Frequency” field 304 , a “Probability” field 306 , and a “Number of Bits” field 308 .
- the probability models can be used to predict the tradeable object that has changed. As mentioned earlier, to ensure that a change in a tradeable object can be represented as a bit sequence, every tradeable object symbol is assigned at least some non-zero probability.
- the first sub-model is a “Tradeable Object Symbol” model 310 that can be used to encode a symbol associated with a specific tradeable object.
- the sub-model 310 includes five tradeable objects, ES-Mar05, ES-Jun05, NQ-Mar05, NQ-Jun05, and “Other” to be used in relation to other tradeable objects that are not specifically defined in the model 310 .
- the models are not limited to any specific tradeable objects and could be defined in relation to fewer, more, or different tradeable objects than those shown in FIG. 3 .
- any parameters described in relation to the model 300 should not be viewed as limiting, but as examples only.
- the “Frequency” field 304 specifies the number of times a change has been detected in relation to a specific tradeable object during a predetermined time period. It should be understood that any time period could be used, such as one or more trading days starting from the time when the markets open, or some other user-defined time interval.
- the frequency data in the probability models are preferably updated such that at the time of encoding certain market data parameter the frequency values at both ends of the network are the same. More details related to updating the probability models will be described below.
- the probability modelers 208 and 216 could monitor changes in market data, and then could update the numbers in the frequency field 304 every time a certain symbol associated with a tradeable object is encoded/decoded.
- the probability modelers 208 and 216 could weigh recent data more heavily than older data. To do that, the modelers could consider only a fixed number of previous encodings in making its predictions. Alternatively, exponential weighting methods could be used to decrease weigh for less recently encoded parameters. Also, rather than starting frequency models from no data at all, the frequency values could be initiated using historical data so that the probability models can be used to make reasonable predictions before being dynamically encoded a sufficient number of times to build the most current probability models. It should be understood that those skilled in the art will understand that different methods could also be used to determine/update the Frequency values.
- the sub-models 312 - 326 correspond to the tradeable object ES-Mar05.
- each tradeable object listed in the Tradeable Object Symbol sub-model 310 would be associated with its own probability models, such as those described below.
- certain tradeable objects could be highly correlated with each other, such as, for example, options on the same tradeable object with similar strike prices and expiration dates.
- a single probability model with a plurality of sub-models could be used to encode/decode more than one tradeable object.
- the frequency of detecting a change in relation to the tradeable object having the symbol ES-Mar05 is 20, as specified in the Frequency column 304 . Based on that frequency value, the probability of detecting a change in relation to market data associated with the tradeable object is 0.487805, as specified in the Probability column 306 .
- the probability of 0.487805 for the ES-Mar05 is determined by dividing the frequency corresponding to the symbol (in this example, 20) by the total number of frequencies corresponding to all tradeable objects in the model (in this example, 41).
- the number of bits to encode the symbol ES-Mar05 is 1.035624, as defined in the “Number of Bits” column 308 .
- the number of bits can be determined using the formula referenced above, “ ⁇ log 2 (p(S)),” which in this example corresponds to ⁇ log 2 (0.487805), or 1.035624 bits. It should be understood that the number of bits could be rounded to a specific number of decimal places predefined to be used in relation to the number of bits and/or probability values.
- the example embodiments described herein in reference to encoding and decoding price levels and quantities use the incremental approach to represent a change in the market.
- the market at any given instant is likely to be quite similar to the market in the previous instant. Often, this number is zero. If it is not zero, it is often either +1 or ⁇ 1, or some other number. While the probability sub-models described below use such incremental approach, it should be understood that different methods to represent a change or specific values could be used as well.
- the probability model 300 further includes the “Best Bid Change” probability sub-model 312 , which can be used to encode the best bid price movement.
- the “Best Bid Change” sub-model 310 for example, the frequency of the best bid being one tick lower than the previous one is 3, and the number of bits that will be used to encode such a change is 2.807355.
- the frequencies of the best bid being at the same market level, at one tick higher, or yet at some other level are also provided in relation to the “Best Bid Change” sub-model 312 , and correspond to the frequencies of 15, 12, and 1, respectively.
- the probability values and the corresponding number of bits to be used to encode and decode each change are shown in columns 306 and 308 .
- quantity related data associated with a plurality of price levels can be encoded as well.
- the process of encoding prices and quantities can be continued until encoding of a preset number of non-zero market depth levels is complete.
- One example quantity encoding/decoding sub-model is illustrated in relation to the “First Qty Change” sub-model 314 .
- the sub-model 314 shows five example values representing a quantity change, including a change by ⁇ 13, ⁇ 10, 0, 10, and “Other.” For example, if there has been no change in the quantity, which corresponds to the “0” change, this information will be represented using 0.807355 bits.
- the quantity change values being used in the “First Qty Change” sub-model 314 can be determined by the probability modelers 208 and 216 based on market activity or prior encodings.
- quantities at price levels other than the best bid price can be encoded and decoded using two probability sub-models.
- the first sub-model can be used to encode and decode whether the quantity at that price level is zero. Then, only if there is pending quantity at the price level, the second sub-model can be used to encode the difference between the new quantity and the last known quantity.
- This specific implementation is shown in relation to the sub-models 316 and 318 .
- the first sub-model 316 is used to encode the information whether the quantity at the second price level (the price level following the best bid) is zero.
- the sub-model 318 can be used to encode the relative level of the current quantity as compared to the previously known quantity at the same price level. It should be understood that negative quantity change values in the probability sub-models that would lead to non-positive quantity can be factored out of the sub-model before encoding any quantity changes.
- the probability model 300 in FIG. 3 illustrates only one sub-model corresponding to a quantity at the price level below the best bid price, additional sub-models could be created as well for additional price levels. Also, while FIG. 3 only shows sub-models corresponding to the bid side of the market, similar sub-models would be developed for prices and quantities corresponding to the ask side of the market.
- the probability sub-models could also be used to encode other parameters that are typically provided in relation to market data.
- the probability model 300 shows one such example in relation to the last traded price and the corresponding last traded quantity.
- the Last Price Change sub-model 320 can be used to encode whether the last traded price is different from the previously provided last traded price. For example, as shown in relation to the sub-model 320 , the probability of the last traded price being different than the previous traded price is 0.45, and such information could be encoded using 1.152003 bits. Then, if the last traded price is different, the type of the current last traded price could be encoded using the probability sub-model “Last Price Type” 322 .
- the “Last Price Type” sub-model 322 defines a few types, including, a previous bid (“Prev Bid”), a previous ask (“Prev Ask”), “Current Bid,” “Current Ask,” and “Other.” While the probability sub-model 322 shows five types that can be used in relation to the last traded price, different definitions could be used as well. Using the probability sub-model 322 , if the current last traded price corresponds to the previous bid, this information can be encoded using 1.169925 bits. Then, the change in the last traded price can be encoded using the “Last Price Change” sub-model 324 . If the last traded price changes by +1 tick, then, such a change can be encoded using bit.
- the quantity corresponding to the last traded quantity can be encoded using the “Last Qty” sub-model 326 .
- the last traded quantity is 10
- that value will be encoded using 0.847997 bits.
- the quantity values illustrated in relation to the sub-model 326 are only examples, and different values could also be specified in the model based on the historical values corresponding to the last traded quantities.
- FIG. 4 is a block diagram 400 illustrating two market depth snapshots 402 and 404 corresponding to a tradeable object at two consecutive times, T1 and T2.
- the two market snapshots include six price levels, ranging from 1175.00 to 1173.75, and the corresponding quantity values. As shown in relation to the market depth 402 corresponding to time T1, the best bid having the quantity of 10 is at the price level of 1174.25, while the best ask corresponds to the price level of 1174.75 and has the quantity of 25.
- the market depth snapshot 402 also indicates that the last traded quantity of 20 was traded at the price level of 1174.75.
- the market depth snapshot 404 illustrates market depth corresponding to the same tradeable object at time T2.
- the market has moved, resulting in the best bid quantity of 10 being now at the price level of 1174.00, and a new available quantity of 10 being at 1173.75. Also, as indicated in relation to the market snapshot 404 , the last traded quantity of 10 was traded at the price level of 1174.25.
- the market data illustrated in FIG. 4 will be used hereinafter to illustrate methods for encoding market data using probability models described in FIG. 3 , and updating the probability models based on the changes in the market data to generate updated probability models.
- FIG. 5 is a message flow diagram 500 illustrating a method for providing market data to a client entity using data encoding based on probability models.
- the message flow diagram 500 will be described in relation to the entities illustrated in FIG. 2 . However, it should be understood that the messages could be used in relation to different network entities as well. Also, while FIG. 5 illustrates a sequence of messages, the example embodiments are not limited to this specific message sequence, and the same operations could be accomplished using more or fewer messages that can be sent in a different order than that shown in FIG. 5 .
- the message flow diagram 500 will be used to illustrate the process of encoding/decoding the change in the best bid price corresponding to the tradeable object based on the market depth data illustrated in FIG. 4 . Also, it will be assumed that the market depth data illustrated in FIG. 4 corresponds to the ES Mar05 having the current probability model illustrated in FIG. 3 .
- the compressor controller 208 may query the probability modeler 210 to get probability data to be used in relation to encoding the best bid price associated with ES Mar05.
- the compressor controller 208 may send a request to the probability modeler 210 , such as a “Get Symbol Prob” request 502 , illustrated in FIG. 5 , to get the probability data for the best bid price corresponding to the ES Mar05.
- the probability modeler 210 may then look up the requested data in the probability models 212 , and provide the requested data to the compressor controller 208 , as shown in “Symbol Prob” 504 .
- the “Get Symbol Prob” request 502 may include an identifier being used for encoding the best bid price corresponding to the ES Mar05.
- the “Symbol Prob” 504 may in turn include the probability value to be used for encoding the change in the best bid price. If the probability value is provided, the encoder 214 may use it to determine the number of bits to be used to encode the change in the best bid price. Alternatively, the “Symbol Prob” 504 could define the number of bits to be used to encode the change in the best bid price.
- the probability of the best bid changing by ⁇ 1 tick is 0.142857, and the number of bits that can be used to encode this change is 2.807355.
- the “Symbol Prob” 504 can include the probability value, the number of bits, or both values.
- the compressor controller 208 may then send a request to the encoder 214 to encode the best bid change, as shown with “Encode (Symbol, Symbol Prob)” 506 .
- the request 506 may include an indicator of the symbol to be encoded, here the best bid, and the symbol probability data, in this example, either the probability value, the number of bits to be used to encode the change, or both.
- the encoder 214 may then encode the change in the best bid price using the provided probability data. According to the example probability sub-model 312 in FIG. 3 , the change in the best bid by ⁇ 1 tick would be encoded using 2.807355 bits. The encoder 214 may then provide the encoded best bid change data back to the compressor controller 208 . The compressor controller 208 may then update the probability sub-model corresponding to the best bid price. This update is illustrated in “Adapt (Symbol)” request 510 .
- the frequency value corresponding to ⁇ 1 tick change in the best bid change probability sub-model will be increased by 1 to the frequency of 4, and the values for the probabilities as well as the number of bits to be used to compress the best bid changes will be recalculated accordingly.
- the updated best bid change probability sub-model is illustrated in relation to FIG. 6 at 612 , more details of which will be described in greater detail below.
- the compressor 206 then sends the compressed and encoded data corresponding to the best bid price change to the decompressor system 216 , as shown at 512 , and the data 512 is received at the decompressor controller 218 .
- the encoder 214 could first encode all changes in the market corresponding to a tradeable object before sending any data; however, different embodiments are possible as well.
- the decompressor controller 218 receives the compressed and encoded data bits corresponding to the best bid price change, it gets the probability data corresponding to the best bid change from the probability modeler 220 , as shown at 514 to decode the received data.
- the probability data at the probability modeler 220 is the same as the probability data that was used to encode the best bid change at the compressor side of the system before updating the corresponding probability sub-model.
- the decoder 224 can correctly decode the received data.
- the decompressor controller 218 receives the probability data, as shown at 516 , it can send the received data and the probability data to the decoder 224 .
- the decoder 224 may provide the decoded bits to the decompressor controller 218 .
- the probability sub-model corresponding to the best bid price change can be updated so that it matches the current best bid price change sub-model at the compressor side of the market, as shown at 522 .
- the updated best bid probability sub-model on the decompressor side will correspond to the sub-model 612 illustrated in FIG. 6 .
- the decompressor controller 218 can provide the data to a trading application for display at the client entity.
- the data could be provided to different applications as well. It should be understood that the same or similar methods could be used to encode/decode other changes in the market.
- FIG. 5 illustrates individual messages being used in relation to a single market data parameter, in an alternative embodiment, a single message can be used to convey information associated with a plurality of market data parameters.
- the “Get Symbol Prob” message 502 can be used to query the probability modeler 210 for probability data corresponding to more than one market data parameter, such as market data parameters other than corresponding to the best bid price, in this example.
- the “Encode” message 506 could include a request to encode more than one market data parameter.
- FIG. 6 is a block diagram illustrating an updated probability model of FIG. 4 based on market data illustrated in FIG. 5 .
- the probability model 600 shows the probability sub-models discussed in relation to FIG. 3 , and updated based on the market changes illustrated in FIG. 4 .
- other sub-models are updated accordingly.
- the “First Qty Change” sub-model 614 has been updated based on the best bid quantity being the same as the previous best bid quantity. As shown in relation to the “First Qty Change” sub-model 614 , the frequency value corresponding to “0” quantity change is updated from 12 to 13.
- the probability values and the number of bits shown in columns 606 and 608 are recomputed accordingly for each best bid change value.
- the quantity changes corresponding to ⁇ 13 and ⁇ 10 could be excluded from the “First Qty Change” sub-model 614 since they would lead to a negative quantity or no quantity at all at the best bid price in relation to the next quantity value of the corresponding bid price.
- the probability values corresponding to “0,” “10,” and “Other” changes would be recomputed accordingly.
- the frequency value corresponding to the “No” parameter is updated from 20 to 21. Also, since the quantity at the price level of 1173.75 has increased from 0 to 10, the frequency value corresponding to the change of 10 in the “2 nd Qty Change” probability sub model 618 is increased from 1 to 2, and the probabilities as well as the values corresponding to the number of bits to be used for encoding data are recalculated accordingly.
- FIG. 4 also shows a change in the last traded price and the last traded quantity, with the last traded price changing from 1174.75 to 1174.25, and the last traded quantity changing from 20 to 10.
- the change in the last traded price is used to update the “Last Price Change” probability sub-model 620 .
- the “Last Price Type” sub-model 622 is updated by increasing the frequency value corresponding to the “Prev Bid” from 4 to 5.
- the last traded price corresponds to one of the price types listed in the “Last Price Type” sub-model 622 , no changes are shown in relation to the “Last Price Change” sub-model 624 .
- the frequency corresponding to the value of “10” in the “Last Qty” sub-model 626 has been updated from 5 to 6.
- FIG. 7 is a flowchart 700 illustrating an example method 700 for encoding market data. It should be understood that each block in this and subsequent flowcharts may represent a module, segment, or portion of code, which includes one or more executable instructions for implementing specific logical functions or steps in the process. Alternate implementations are included within the scope of the example embodiments in which functions may be executed out of order from that shown or discussed, including substantially concurrently or in reverse order, depending on the functionality involved, as would be understood by those reasonably skilled in the art of the present invention.
- the flowchart 700 will be described in relation to the components illustrated in FIG. 2 . However, it should be understood that more, fewer, or different components could also be used to execute the method 700 .
- the encoder 214 encodes a symbol corresponding to a tradeable object with respect to which a change in market data has been detected. It should be understood that each step of encoding in FIG. 7 involves using methods and probability models discussed in relation to the preceding figures.
- the encoder 214 encodes a change in the best bid price corresponding to the tradeable object. As explained in relation to preceding figures, encoding a change in the best bid price may include encoding that there has been no change in the best bid price.
- the encoder 214 encodes a quantity change corresponding to the best bid.
- the encoder moves to the next price level on the bid side of the market corresponding to the tradeable object.
- the encoder 214 determines if the quantity at the next price level is zero. Then, if the quantity at the next price level is zero, at step 712 , the encoder 214 encodes it as “True,” and moves to the next price level on the bid side of the market, as shown at 708 . Referring back to step 710 , if the quantity at that price level is not zero, the encoder 214 encodes it as “False,” as shown at 714 . Then, since the quantity is not zero, at 716 , the encoder 214 can encode the quantity change.
- the exchange 204 may provide a certain number of market depth levels, and, based on that number, the encoder 214 may be programmed to encode and provide a certain number of market depth levels to the client entity 202 . It should be understood that the number of market depth levels to be encoded at the encoder 214 could be the same or lower than that being normally provided from the exchange 204 . Also, the number of market depth levels to be encoded by the encoder 214 may be determined by the number of non-zero market depth level, e.g., the market depth levels having non-zero quantity values. At step 718 , the encoder 214 determines if enough non-zero market depth levels have been already encoded. If not, the method 700 continues at step 708 .
- the encoder 214 proceeds to encoding the ask side of the market corresponding to the tradeable object.
- the encoder 214 could encode the ask side of the market by following the steps that were used to encode the bid side of the market, which in this example correspond to steps 704 - 718 .
- the encoder 214 When the encoder 214 encodes the market depth information, it can also encode other market related parameters.
- the method 700 illustrates the process that can used to encode the last traded price and the last traded quantity. However, it should be understood that different parameters could be encoded using the same or similar methods.
- the encoder 214 determines if data related to the last trade has changed. If no changes in the last traded quantity or price have been detected the method 700 terminates. Otherwise, at step 724 , the encoder 214 encodes the type of the last traded price.
- the type of the last traded price could be a last bid, a last ask, or yet different types, the examples of which were defined earlier.
- the encoder 214 determines if the last price type was encoder as “Other.” If so, at 728 , the encoder 214 will encode the change in the last traded price. At step 730 , the encoder 214 may encode the last traded quantity, and the method 700 terminates. As mentioned earlier, the method 700 could continue if the encoder 214 is programmed to encode additional market data related parameters.
- FIG. 8 is a flowchart illustrating an example method 800 for decoding market data.
- the decoder 224 may first decode the symbol corresponding to a tradeable object associated with the received data. Similarly to the method 700 , it should be understood that each decoding step described in relation to the method 800 may involve using the probability models and methods described above.
- the decoder 224 may decode a change in the best bid price.
- the decoder 224 decodes a change in the best bid price and the best bid quantity.
- the decoder 224 may move to decoding the next price level.
- the decoder 224 decodes the bit sequence defining if the next price level is zero.
- the decoder 224 determines if the next price level is zero. If it is, at step 814 , it sets the quantity level at that price level to zero, and the method 800 continues at step 808 . Referring back to step 812 , if the price level is not zero, at step 816 , the decoder 224 decodes a quantity change corresponding to that price level. At step 818 , the decoder 224 determines if it has decoded enough non-zero price levels. It should be understood that this number can be preconfigured on the decoder, or it could be provided in relation to the encoded data received from the exchange. If not enough non-zero price levels have been decoded, the method 800 continues at step 808 . Otherwise the steps described above in relation to decoding the bid side of the market are repeated for the ask side of the market, as shown at step 820 .
- the decoder 224 may proceed to decoding other market related parameters. Decoding of such parameters will be described in relation to decoding data related to the last trade; however, different parameters could be decoded as well.
- the decoder 224 decodes data defining if the last trade has changed.
- the decoder 224 determines if the last trade has changed. If the last trade has not changed, the method 800 terminates. Otherwise, at step 826 , the decoder 224 decodes the last traded price type.
- the decoder 224 determines if the last traded price type was decoded to be “Other.” If it was not, the method continues at step 832 . If it was, at step 830 , the decoder 224 decodes the last traded price change. Then, at step 832 , the decoder 224 decodes the last traded quantity, and the method 800 terminates.
- a computer readable medium can include a readable memory device, such as a hard drive device, a CD-ROM, a DVD-ROM, or a computer diskette, having computer readable program code segments stored thereon.
- the computer readable medium can also include a communications or transmission medium, such as, a bus or a communication link, either optical, wired or wireless having program code segments carried thereon as digital or analog data signals.
Landscapes
- Business, Economics & Management (AREA)
- Engineering & Computer Science (AREA)
- Finance (AREA)
- Accounting & Taxation (AREA)
- Development Economics (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- Economics (AREA)
- Marketing (AREA)
- Strategic Management (AREA)
- Technology Law (AREA)
- Entrepreneurship & Innovation (AREA)
- Operations Research (AREA)
- Human Resources & Organizations (AREA)
- Game Theory and Decision Science (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
A system and methods are developed for providing market data in an electronic trading environment. One example method includes determining a probability model comprising a probability corresponding to a change in relation to a market data parameter, then, using the probability to generate a compressed bit stream representing the market data parameter, and providing the compressed bit stream to the client terminal.
Description
- This application is a continuation of U.S. patent application Ser. No. 14/496,047, filed on Sep. 25, 2014, which is a continuation of U.S. patent application Ser. No. 13/899,835, filed on May 22, 2013, now U.S. Pat. No. 8,874,478, which is a continuation of U.S. patent application Ser. No. 13/491,169, filed on Jun. 7, 2012, now U.S. Pat. No. 8,473,405, which is a continuation of U.S. patent application Ser. No. 12/771,930, filed on Apr. 30, 2010, now U.S. Pat. No. 8,219,482, which is a continuation of U.S. patent application Ser. No. 11/095,100, filed on Mar. 31, 2005, now U.S. Pat. No. 7,739,184. The entire contents of each of these applications are herewith incorporated by reference into the present application for all purposes.
- The present invention is directed to electronic trading. More specifically, the present invention is directed towards providing market data in an electronic trading environment.
- Trading methods have evolved from an exclusively manual process to a technology enabled, electronic platform. With the advent of electronic trading, a user or trader can be in virtually direct contact with the market, from practically anywhere in the world, performing near real-time transactions, and without the need to make personal contact with a broker.
- In particular, traders are connected to an exchange's electronic trading platform by way of a communication link and through an application program interface to facilitate real-time electronic messaging between themselves and the exchange. The electronic trading platform includes at least one electronic market, which is the heart of the trading system for a particular tradeable object and handles matching of bids and offers placed by the subscribing traders for that tradeable object. The electronic messaging includes market information that is sent from the electronic exchange to the traders. Once the traders receive market information, it may be displayed to them on their trading screens. Upon viewing the information, traders can take certain actions, including the actions of sending buy or sell orders to the electronic exchange, adjusting existing orders, deleting orders, or otherwise managing orders. Traders may also use software tools on their client devices to automate these and additional actions.
- Just as with an open-outcry exchange, an electronic exchange can list any number of tradeable objects. Often times, traders will trade simultaneously more than one tradeable object, and they may trade simultaneously tradeable objects that are listed at more than one exchange. As used herein, the term “tradeable object” refers to anything that can be traded with a quantity and/or price. It includes, but is not limited to, all types of traded events, goods and/or financial products, which can include, for example, stocks, options, bonds, futures, currency, and warrants, as well as funds, derivatives and collections of the foregoing, and all types of commodities, such as grains, energy, and metals. The tradeable object may be “real,” such as products that are listed by an exchange for trading, or “synthetic,” such as a combination of real products that is created by the user. A tradeable object could actually be a combination of other tradeable objects, such as a class of tradeable objects.
- Ordinarily, each tradeable object has its own independent electronic market, and therefore, its own separate stream of market data, commonly referred to as a data feed. A data feed includes market information corresponding to a tradeable object, and the content of the data feed typically depends on the host exchange and on the tradeable object. Market information in a data feed commonly includes information related to the inside market and market depth. The inside market represents the lowest sell price (also referred to as the best or lowest ask price), and the highest buy price (also, referred to as the best or highest bid price). Then, market depth includes quantities available for trading the tradeable object at certain buy and sell price levels away from the inside market. The extent of market depth available for a trader usually depends on the exchange. For example, some exchanges provide market depth for an infinite number of price levels, while some provide only quantities associated with the inside market, and others may provide no market depth at all. Additionally, exchanges can offer other types of market information in the data feeds, such as the last traded price (LTP), the last traded quantity (LTQ), and order fill information.
- Since each tradeable object is actually associated with its own separate stream of market information, in the instances when a trader trades more than one tradeable object, the trader will receive more than one data feed. In addition to receiving market information from exchanges, traders might subscribe to news feeds, real-time quotation vendors that provide information to traders for decision support, and other information sources.
- Using client devices, such as a personal computer, laptop computer, hand-held computer, or other devices that have network access, a trader can link to host exchanges through one or more networks. A network is a group of two or more computers or devices linked together, and characterized by topology, protocol, and architecture. For example, some traders may link to the host through a direct network connection, such as a T1 or ISDN. Others may link to the host exchange through direct network connections, and through other common network components, such as high speed servers, routers, and gateways. The Internet, a well-known collection of networks and gateways, can be used to establish a connection between the client device and the host exchange. There are many different types of wired and wireless networks and combinations of network types known in the art that can link traders to the host exchange.
- Many, if not all, networks being used by electronic exchanges have limited bandwidth capacity. Since adding network bandwidth is very expensive, many existing exchanges already limit the extent of market data being provided to their clients. Also, as the trading applications become more and more sophisticated, traders may wish to receive more content rich market data. Thus, it would be beneficial to provide a trading system that can meet current and future bandwidth needs.
- Example embodiments are described herein with reference to the following drawings, in which:
-
FIG. 1 is a block diagram illustrating an example network configuration that can be used to access one or more electronic exchanges; -
FIG. 2 is a block diagram illustrating an example system that can be used for market data compression according to one example embodiment; -
FIG. 3 is a block diagram illustrating an example probability model that can be defined in relation to a tradeable object; -
FIG. 4 is a block diagram illustrating two market depth snapshots corresponding to a tradeable object at two consecutive times; -
FIG. 5 is a message flow diagram illustrating an example method for providing market data to a client entity using data encoding based on probability models; -
FIG. 6 is a block diagram illustrating an updated probability model ofFIG. 4 based on market data changes illustrated inFIG. 5 ; -
FIG. 7 is a flowchart illustrating an example method for encoding market data according to one example embodiment; and -
FIG. 8 is a flowchart illustrating an example method for decoding market data according to one example embodiment. - The example embodiments, among other things, are directed to providing market data to client devices. Typical market data consists of a collection of prices and quantities corresponding to a tradeable object. In general, for any given tradeable object, the market at any instant is likely to be quite similar to the market in the previous instant, with the change being often zero. If the market moves, it often changes by +/−1 tick. These, as well as other market characteristics, are used in the example methods and systems described herein to develop statistical probability models for use in relation to statistical compression of market data.
- More specifically, according to one example system, a sending entity, such as an electronic exchange, or yet some other entity in communication with the exchange, may include a probability modeler that dynamically develops a probability model for a tradeable object. For example, the probability model can be developed and dynamically updated based on market data being encoded and sent to a receiving entity, such as a client entity, over the network from the electronic exchange. More specifically, the probability model for a tradeable object may include a plurality of probability values corresponding to many different market data parameters. For example, the probability model may include a probability for detecting a change of +1 tick in relation to the best bid price in the market corresponding to the tradeable object. According to one example embodiment, the probability values in the model corresponding to the change in the best bid price may be determined based on how many times a change of +1 tick has been encoded in relation to the best bid price during a certain time period in the past. The statistical compressions methods can then use the developed probability model to generate a compressed bit stream representing the change in best bid price, as well as other market data changes, corresponding to the tradeable object. The compressed bit stream may then be sent over one or more networks to the client entity.
- According to one example embodiment, a receiving entity also includes probability models that are used to decode received compressed bit streams. In such an embodiment, the probability model that was used at the time of encoding a change in a certain market parameter is the same as the one that is used at the receiving entity at the time of decoding the change. To keep the two probability models synchronized, the models can be updated after encoding and decoding the change corresponding to the market parameter. More details related to market data compression using probability models will be described below.
- While the example embodiments are described herein with reference to illustrative embodiments for particular applications, it should be understood that the example embodiments are not limited thereto. Other systems, methods, and advantages of the present embodiments will be or become apparent to one with skill in the art upon examination of the following drawings and description. It is intended that all such additional systems, methods, features, and advantages be within the scope of the present invention, and be protected by the accompanying claims.
- As will be appreciated by one of ordinary skill in the art, the example embodiments may be operated in an entirely software embodiment, in an entirely hardware embodiment, or in a combination thereof. However, for sake of illustration, the example embodiments are described in a software-based embodiment, which is executed on a computer device. As such, the example embodiments take the form of a computer program product that is stored on a computer readable storage medium and is executed by a suitable instruction system in the computer device. Any suitable computer readable medium may be utilized including hard disks, CD-ROMs, optical storage devices, or magnetic storage devices, for example.
- In an electronic trading environment, when an authorized trader selects a tradeable object, the trader may access market data related to the selected tradeable object(s). Referring to
FIG. 1 , an example communication that might occur between an electronic exchange and a client entity is shown. During a trading session,market data 108, in the form of messages, may be relayed from ahost exchange 106 overcommunication links client entity 102 may be a single client terminal that is used by a single trader or multiple client terminals corresponding to multiple traders associated with one or more trading groups. Theclient entity 102 may include any computer that accesses one or more networks. For example, theclient entity 102 can be a personal computer, a laptop computer, a hand-held device, and so on. - As illustrated in
FIG. 1 , intermediate devices, such as gateway(s) 104, may be used to facilitate communications between theclient entity 102 and thehost exchange 106. It should be understood that whileFIG. 1 illustrates theclient entity 102 communicating with asingle host exchange 106, in an alternative embodiment, theclient entity 102 could establish trading sessions to more than one host exchange. Also, it should be understood that information being communicated to and from theclient entity 102 and theexchange 106 could be communicated via a single communication path. - The
market data 108 contains information that characterizes the tradeable objects, including, among other parameters, order related parameters, such as price and quantity, and the inside market, which represents the lowest sell price (also referred to as the best or lowest ask price), and the highest buy price (also referred to as the best or highest bid price). In some electronic markets, market data may also include market depth, which generally refers to quantities available for trading the tradeable object at certain buy price levels and quantities available for trading the tradeable object at certain sell price levels. The methods for providing market data according to the example embodiments will be described in greater detail below. - In addition to providing the tradeable object's order book information, electronic exchanges can offer different types of market information such as total traded quantity for each price level, opening price, last traded price, last traded quantity, closing price, or order fill information. It should be understood that market information provided from an electronic exchange could include more or fewer items depending on the type of tradeable object or the type of exchange. Also, it should be understood that the messages provided in the
market data 108 may vary in size depending on the content carried by them, and the software at the receiving end may be programmed to understand the messages and to act out certain operations. - A trader may view the information provided from an exchange via one or more specialized trading screens created by software running on the
client entity 102. Upon viewing the market information or a portion thereof, a trader may wish to take actions, such as send orders to an exchange, cancel orders at the exchange, or change order parameters, for example. To do that, the trader may input various commands or signals into theclient entity 102. Upon receiving one or more commands or signals from the trader, theclient entity 102 may generate messages that reflect the actions taken, generally shown at 110. It should be understood that different types of messages or order types can be submitted to thehost exchange 106, all of which may be considered various types of transaction information. Once generated, user action messages 110 may be sent from theclient entity 102 to the host exchange overcommunication links - The
client entity 102 may use software that creates specialized interactive trading screens on theclient entity 102. The trading screens enable traders to enter and execute orders, obtain market quotes, and monitor positions. The range and quality of features available to the trader on his or her screens varies according to the specific software application being run. In addition to or in place of the interactive trading screens, theclient entity 102 may run automated non-interactive types of trading applications. - A commercially available trading application that allows a user to trade in systems like those shown in
FIG. 1 and subsequent figures is X_TRADER® from Trading Technologies International, Inc. of Chicago, Ill. X_TRADER® also provides an electronic trading interface, referred to as MD Trader™, in which working orders and bid/ask quantities are displayed in association with a static price axis or scale. As mentioned above, the scope of the example embodiments described herein are not limited by the type of terminal or device used, and are not limited to any particular type of trading application. Portions of the X_TRADER® and the MD Trader™-style display are described in U.S. Pat. No. 6,772,132 entitled “Click Based Trading With Intuitive Grid Display of Market Depth,” filed on Jun. 9, 2000, U.S. patent application Ser. No. 09/971,087, entitled “Click Based Trading With Intuitive Grid Display of Market Depth and Price Consolidation,” filed on Oct. 5, 2001, and U.S. patent application Ser. No. 10/125,894, entitled “Trading Tools for Electronic Trading,” filed on Apr. 19, 2002, the contents of each are incorporated herein by reference. - A. Market Data Compression System Architecture
-
FIG. 2 is a block diagram illustrating anexample system 200 that can be used for market data compression according to one example embodiment. Theexample system 200 illustrates aclient entity 202 and anelectronic exchange 204 communicating via anetwork 222. According to the example embodiments that will be described in greater detail below, theelectronic exchange 204 uses statistical compression techniques to compress market data that is provided to theclient entity 202. WhileFIG. 2 shows only certain elements of theexchange 204 andclient entity 202 that can be used in relation to data compression/decompression, it should be understood that a typical exchange and a client entity may include many additional elements, such as interfaces, processors, and applications, that can be used for receiving and processing data being communicated between theexchange 204 and theclient entity 202. Also, it should be understood that whileFIG. 2 illustrates asingle network 222 that is used for sending data between theclient entity 202 and theelectronic exchange 204, the two entities could communicate via multiple networks and additional intermediate devices, such as gateways, routers, or yet some other network devices. Additionally, while the compression elements are illustrated as being part of theexchange 204, alternatively, these elements could be located on some other network entity in communication with theelectronic exchange 204. - The
electronic exchange 204 includes acompressor system 206. The compressor system in turn includes acontroller 208, aprobability modeler 210, and anencoder 214. Theclient entity 102 includes adecompressor system 216 with acontroller 218, aprobability modeler 220, and adecoder 224. Thecompressor system 206 can use one or more compression algorithms that are to compress market data using statistical probability data according to the embodiments that will be described in greater detail below. Thedecompressor system 216 can use one or more decompression algorithms along with the statistical probability data to decompress any compressed data received from theelectronic exchange 202. The principals of statistical data encoding and decoding are well known in the art, and more details related to these processes can be found, for example, in the publication “Arithmetic Coding Revealed,” by Eric Bodden, et al., fully incorporated herein by reference. The relevant theorem being relied on herein is that the minimum number of compressed bits that can be used to represent a symbol is “−log2(p(S)),” where “S” is the symbol/parameter to be encoded, and “p” is the probability predicted for the symbol/parameter. The symbols, as used hereinafter, can refer to any parameter related to market data, such as a symbol being used to identify a tradeable object, a market level, a price level, or yet a different parameter associated with market data. - As an example, using “−log2(p(S))” to determine a minimum number of bits that can be used to represent a symbol, if the probability of occurrence of a symbol is 0.25, the symbol could be represented with −log2(0.25) bits, or 2 bits. It should be understood that the number of bits that can be used to represent a symbol does not necessarily have to be represented with integer numbers. Alternatively, the number of bits could be represented with decimal numbers as well. For example, if a symbol is predicted with probability of 0.9, it would be represented with −log2(0.9) bits, or approximately 0.152 bits. In relation to encoding market data parameters, such as encoding changes in the inside market prices or quantities, the above equation would take a format of −log2(Tradeable Object Parameter Probabability).
- The probability modelers 210 and 220 generate market
data probability models FIG. 2 , thecompressor system 206 uses theprobability models 212 to compress and encode market data and generate a compressed data stream to be sent to theclient entity 202. Similarly, theprobability models 222 can be used at theclient entity 202 to decode and decompress received compressed data stream. The probability models include statistical data representing the probabilities of detecting a change in relation to certain parameters associated with market data, the examples of which will be described in relation to subsequent figures. - The probability models could be dynamic or static. The example embodiments hereinafter describe probability models that are dynamically generated and updated during a trading day based on a frequency or history of changes in relation to certain parameters that the modeler has already seen. For example, the probability model for symbols A, B, and C that has seen the sequence of symbols ABACAABC, where, for example, the symbols correspond to changes detected in relation to three market levels, the
probability modelers probability models controllers - According to one example embodiment, each tradeable object could be associated with its own probability model.
FIG. 2 shows a plurality of probability models created for a plurality of tradeable objects, “TO 1” through “TO X.” Each tradeable object probability model may in turn include a number of probability sub-models. A probability sub-model may define probability levels for one or more market data parameters associated with the tradeable object. As mentioned earlier, typical market data that will be compressed consists of a collection of prices and quantities corresponding to a tradeable object. For each tradeable object, there are two sides of market depth, a bid side and an ask side, along with a variety of different parameters, such as a last traded price and a last traded quantity. The market depth, as mentioned earlier, may include a preset number of levels ranging from only the inside market to an unlimited number of levels. While the number of market depth levels that will be compressed may be equal to the number of market depth levels typically provided by the exchange, fewer market depth levels could be compressed as well. -
FIG. 3 is a block diagram illustrating anexample probability model 300 that can be defined in relation to a tradeable object. Theprobability model 300 includes a “Parameter”field 302, a “Frequency”field 304, a “Probability”field 306, and a “Number of Bits”field 308. When sending market data, the probability models can be used to predict the tradeable object that has changed. As mentioned earlier, to ensure that a change in a tradeable object can be represented as a bit sequence, every tradeable object symbol is assigned at least some non-zero probability. - As shown in
FIG. 3 , the first sub-model is a “Tradeable Object Symbol”model 310 that can be used to encode a symbol associated with a specific tradeable object. The sub-model 310 includes five tradeable objects, ES-Mar05, ES-Jun05, NQ-Mar05, NQ-Jun05, and “Other” to be used in relation to other tradeable objects that are not specifically defined in themodel 310. It should be understood that the models are not limited to any specific tradeable objects and could be defined in relation to fewer, more, or different tradeable objects than those shown inFIG. 3 . Also, any parameters described in relation to themodel 300 should not be viewed as limiting, but as examples only. - The “Frequency”
field 304 specifies the number of times a change has been detected in relation to a specific tradeable object during a predetermined time period. It should be understood that any time period could be used, such as one or more trading days starting from the time when the markets open, or some other user-defined time interval. The frequency data in the probability models are preferably updated such that at the time of encoding certain market data parameter the frequency values at both ends of the network are the same. More details related to updating the probability models will be described below. According to one example embodiment, theprobability modelers frequency field 304 every time a certain symbol associated with a tradeable object is encoded/decoded. To improve accuracy of frequency data, theprobability modelers - The sub-models 312-326 correspond to the tradeable object ES-Mar05. According to one example embodiment, each tradeable object listed in the Tradeable
Object Symbol sub-model 310 would be associated with its own probability models, such as those described below. Alternatively, certain tradeable objects could be highly correlated with each other, such as, for example, options on the same tradeable object with similar strike prices and expiration dates. In such an embodiment, a single probability model with a plurality of sub-models could be used to encode/decode more than one tradeable object. Those skilled in the art will appreciate that different variations of grouping and developing the probability models described herein are possible as well. - Referring to the
probability model 300, the frequency of detecting a change in relation to the tradeable object having the symbol ES-Mar05 is 20, as specified in theFrequency column 304. Based on that frequency value, the probability of detecting a change in relation to market data associated with the tradeable object is 0.487805, as specified in theProbability column 306. According to the example embodiment inFIG. 3 , the probability of 0.487805 for the ES-Mar05 is determined by dividing the frequency corresponding to the symbol (in this example, 20) by the total number of frequencies corresponding to all tradeable objects in the model (in this example, 41). The number of bits to encode the symbol ES-Mar05 is 1.035624, as defined in the “Number of Bits”column 308. According to the example embodiments presented herein, the number of bits can be determined using the formula referenced above, “−log2(p(S)),” which in this example corresponds to −log2(0.487805), or 1.035624 bits. It should be understood that the number of bits could be rounded to a specific number of decimal places predefined to be used in relation to the number of bits and/or probability values. - The example embodiments described herein in reference to encoding and decoding price levels and quantities use the incremental approach to represent a change in the market. In general, for any given tradeable object, the market at any given instant is likely to be quite similar to the market in the previous instant. Often, this number is zero. If it is not zero, it is often either +1 or −1, or some other number. While the probability sub-models described below use such incremental approach, it should be understood that different methods to represent a change or specific values could be used as well.
- The
probability model 300 further includes the “Best Bid Change”probability sub-model 312, which can be used to encode the best bid price movement. According to the “Best Bid Change”sub-model 310, for example, the frequency of the best bid being one tick lower than the previous one is 3, and the number of bits that will be used to encode such a change is 2.807355. The frequencies of the best bid being at the same market level, at one tick higher, or yet at some other level are also provided in relation to the “Best Bid Change”sub-model 312, and correspond to the frequencies of 15, 12, and 1, respectively. The probability values and the corresponding number of bits to be used to encode and decode each change are shown incolumns - In addition to encoding data related to price levels, such as the best bid price, quantity related data associated with a plurality of price levels can be encoded as well. According to one example embodiment, the process of encoding prices and quantities can be continued until encoding of a preset number of non-zero market depth levels is complete. One example quantity encoding/decoding sub-model is illustrated in relation to the “First Qty Change”
sub-model 314. The sub-model 314 shows five example values representing a quantity change, including a change by −13, −10, 0, 10, and “Other.” For example, if there has been no change in the quantity, which corresponds to the “0” change, this information will be represented using 0.807355 bits. It should be understood that the quantity change values being used in the “First Qty Change” sub-model 314 can be determined by theprobability modelers - According to one example embodiment, quantities at price levels other than the best bid price can be encoded and decoded using two probability sub-models. The first sub-model can be used to encode and decode whether the quantity at that price level is zero. Then, only if there is pending quantity at the price level, the second sub-model can be used to encode the difference between the new quantity and the last known quantity. This specific implementation is shown in relation to the sub-models 316 and 318. The
first sub-model 316 is used to encode the information whether the quantity at the second price level (the price level following the best bid) is zero. Then, the sub-model 318 can be used to encode the relative level of the current quantity as compared to the previously known quantity at the same price level. It should be understood that negative quantity change values in the probability sub-models that would lead to non-positive quantity can be factored out of the sub-model before encoding any quantity changes. - It should be understood that while the
probability model 300 inFIG. 3 illustrates only one sub-model corresponding to a quantity at the price level below the best bid price, additional sub-models could be created as well for additional price levels. Also, whileFIG. 3 only shows sub-models corresponding to the bid side of the market, similar sub-models would be developed for prices and quantities corresponding to the ask side of the market. - In addition to encoding prices and corresponding quantities, the probability sub-models could also be used to encode other parameters that are typically provided in relation to market data. The
probability model 300 shows one such example in relation to the last traded price and the corresponding last traded quantity. The LastPrice Change sub-model 320 can be used to encode whether the last traded price is different from the previously provided last traded price. For example, as shown in relation to the sub-model 320, the probability of the last traded price being different than the previous traded price is 0.45, and such information could be encoded using 1.152003 bits. Then, if the last traded price is different, the type of the current last traded price could be encoded using the probability sub-model “Last Price Type” 322. The “Last Price Type”sub-model 322 defines a few types, including, a previous bid (“Prev Bid”), a previous ask (“Prev Ask”), “Current Bid,” “Current Ask,” and “Other.” While theprobability sub-model 322 shows five types that can be used in relation to the last traded price, different definitions could be used as well. Using theprobability sub-model 322, if the current last traded price corresponds to the previous bid, this information can be encoded using 1.169925 bits. Then, the change in the last traded price can be encoded using the “Last Price Change”sub-model 324. If the last traded price changes by +1 tick, then, such a change can be encoded using bit. It should be understood that similar probability sub-models could be defined for different market related parameters as well, and the example embodiments are not limited to the last traded price only. The quantity corresponding to the last traded quantity can be encoded using the “Last Qty”sub-model 326. For example, if the last traded quantity is 10, that value will be encoded using 0.847997 bits. It should be understood that the quantity values illustrated in relation to the sub-model 326 are only examples, and different values could also be specified in the model based on the historical values corresponding to the last traded quantities. -
FIG. 4 is a block diagram 400 illustrating twomarket depth snapshots market depth 402 corresponding to time T1, the best bid having the quantity of 10 is at the price level of 1174.25, while the best ask corresponds to the price level of 1174.75 and has the quantity of 25. Themarket depth snapshot 402 also indicates that the last traded quantity of 20 was traded at the price level of 1174.75. Themarket depth snapshot 404 illustrates market depth corresponding to the same tradeable object at time T2. According to thesnapshot 404, the market has moved, resulting in the best bid quantity of 10 being now at the price level of 1174.00, and a new available quantity of 10 being at 1173.75. Also, as indicated in relation to themarket snapshot 404, the last traded quantity of 10 was traded at the price level of 1174.25. The market data illustrated inFIG. 4 will be used hereinafter to illustrate methods for encoding market data using probability models described inFIG. 3 , and updating the probability models based on the changes in the market data to generate updated probability models. -
FIG. 5 is a message flow diagram 500 illustrating a method for providing market data to a client entity using data encoding based on probability models. The message flow diagram 500 will be described in relation to the entities illustrated inFIG. 2 . However, it should be understood that the messages could be used in relation to different network entities as well. Also, whileFIG. 5 illustrates a sequence of messages, the example embodiments are not limited to this specific message sequence, and the same operations could be accomplished using more or fewer messages that can be sent in a different order than that shown inFIG. 5 . - The message flow diagram 500 will be used to illustrate the process of encoding/decoding the change in the best bid price corresponding to the tradeable object based on the market depth data illustrated in
FIG. 4 . Also, it will be assumed that the market depth data illustrated inFIG. 4 corresponds to the ES Mar05 having the current probability model illustrated inFIG. 3 . - Referring to
FIG. 5 , when thecompressor system 206 detects a request to encode a change in the best bid price, such as, in this example, a change from 1174.25 to 1174.00, thecompressor controller 208 may query theprobability modeler 210 to get probability data to be used in relation to encoding the best bid price associated with ES Mar05. According to one example embodiment, thecompressor controller 208 may send a request to theprobability modeler 210, such as a “Get Symbol Prob”request 502, illustrated inFIG. 5 , to get the probability data for the best bid price corresponding to the ES Mar05. Theprobability modeler 210 may then look up the requested data in theprobability models 212, and provide the requested data to thecompressor controller 208, as shown in “Symbol Prob” 504. The “Get Symbol Prob”request 502 may include an identifier being used for encoding the best bid price corresponding to the ES Mar05. The “Symbol Prob” 504 may in turn include the probability value to be used for encoding the change in the best bid price. If the probability value is provided, theencoder 214 may use it to determine the number of bits to be used to encode the change in the best bid price. Alternatively, the “Symbol Prob” 504 could define the number of bits to be used to encode the change in the best bid price. - Referring back to the example market depth data in
FIG. 4 and the probability model inFIG. 3 , the probability of the best bid changing by −1 tick is 0.142857, and the number of bits that can be used to encode this change is 2.807355. According to the example embodiment, the “Symbol Prob” 504 can include the probability value, the number of bits, or both values. Referring back toFIG. 5 , thecompressor controller 208 may then send a request to theencoder 214 to encode the best bid change, as shown with “Encode (Symbol, Symbol Prob)” 506. Therequest 506 may include an indicator of the symbol to be encoded, here the best bid, and the symbol probability data, in this example, either the probability value, the number of bits to be used to encode the change, or both. - The
encoder 214 may then encode the change in the best bid price using the provided probability data. According to theexample probability sub-model 312 inFIG. 3 , the change in the best bid by −1 tick would be encoded using 2.807355 bits. Theencoder 214 may then provide the encoded best bid change data back to thecompressor controller 208. Thecompressor controller 208 may then update the probability sub-model corresponding to the best bid price. This update is illustrated in “Adapt (Symbol)”request 510. More specifically, according to one example embodiment used in relation to the probability models described herein, the frequency value corresponding to −1 tick change in the best bid change probability sub-model will be increased by 1 to the frequency of 4, and the values for the probabilities as well as the number of bits to be used to compress the best bid changes will be recalculated accordingly. The updated best bid change probability sub-model is illustrated in relation toFIG. 6 at 612, more details of which will be described in greater detail below. - The
compressor 206 then sends the compressed and encoded data corresponding to the best bid price change to thedecompressor system 216, as shown at 512, and thedata 512 is received at thedecompressor controller 218. It should be understood that, in another embodiment, theencoder 214 could first encode all changes in the market corresponding to a tradeable object before sending any data; however, different embodiments are possible as well. When thedecompressor controller 218 receives the compressed and encoded data bits corresponding to the best bid price change, it gets the probability data corresponding to the best bid change from theprobability modeler 220, as shown at 514 to decode the received data. According to the example embodiment, the probability data at theprobability modeler 220 is the same as the probability data that was used to encode the best bid change at the compressor side of the system before updating the corresponding probability sub-model. Using the same probability data, thedecoder 224 can correctly decode the received data. When thedecompressor controller 218 receives the probability data, as shown at 516, it can send the received data and the probability data to thedecoder 224. Upon decoding the data, thedecoder 224 may provide the decoded bits to thedecompressor controller 218. Upon decoding the received data, the probability sub-model corresponding to the best bid price change can be updated so that it matches the current best bid price change sub-model at the compressor side of the market, as shown at 522. In the example provided herein, the updated best bid probability sub-model on the decompressor side will correspond to the sub-model 612 illustrated inFIG. 6 . - Once the received data is decoded and decompressed, the
decompressor controller 218 can provide the data to a trading application for display at the client entity. The data could be provided to different applications as well. It should be understood that the same or similar methods could be used to encode/decode other changes in the market. Also, it should be understood that whileFIG. 5 illustrates individual messages being used in relation to a single market data parameter, in an alternative embodiment, a single message can be used to convey information associated with a plurality of market data parameters. For example, the “Get Symbol Prob”message 502 can be used to query theprobability modeler 210 for probability data corresponding to more than one market data parameter, such as market data parameters other than corresponding to the best bid price, in this example. Similarly, the “Encode”message 506 could include a request to encode more than one market data parameter. -
FIG. 6 is a block diagram illustrating an updated probability model ofFIG. 4 based on market data illustrated inFIG. 5 . Theprobability model 600 shows the probability sub-models discussed in relation toFIG. 3 , and updated based on the market changes illustrated inFIG. 4 . In addition to modification of the “Best Bid Change” sub-model 612 based on a change in the best bid price by −1 tick, other sub-models are updated accordingly. The “First Qty Change”sub-model 614 has been updated based on the best bid quantity being the same as the previous best bid quantity. As shown in relation to the “First Qty Change”sub-model 614, the frequency value corresponding to “0” quantity change is updated from 12 to 13. Then, the probability values and the number of bits shown incolumns FIG. 6 , since the current quantity value is 10, the quantity changes corresponding to −13 and −10 could be excluded from the “First Qty Change” sub-model 614 since they would lead to a negative quantity or no quantity at all at the best bid price in relation to the next quantity value of the corresponding bid price. In such an embodiment, the probability values corresponding to “0,” “10,” and “Other” changes would be recomputed accordingly. - Referring next to the “Is 2nd Zero”
probability sub-model 616, since the quantity available at the next to the best available bid price, here the price level of 1173.75, is not zero, the frequency value corresponding to the “No” parameter is updated from 20 to 21. Also, since the quantity at the price level of 1173.75 has increased from 0 to 10, the frequency value corresponding to the change of 10 in the “2nd Qty Change”probability sub model 618 is increased from 1 to 2, and the probabilities as well as the values corresponding to the number of bits to be used for encoding data are recalculated accordingly. -
FIG. 4 also shows a change in the last traded price and the last traded quantity, with the last traded price changing from 1174.75 to 1174.25, and the last traded quantity changing from 20 to 10. The change in the last traded price is used to update the “Last Price Change”probability sub-model 620. Also, since the last traded price corresponds to the previous bid price, the “Last Price Type”sub-model 622 is updated by increasing the frequency value corresponding to the “Prev Bid” from 4 to 5. Also, since the last traded price corresponds to one of the price types listed in the “Last Price Type”sub-model 622, no changes are shown in relation to the “Last Price Change”sub-model 624. Finally, since the last traded quantity is 10, the frequency corresponding to the value of “10” in the “Last Qty” sub-model 626 has been updated from 5 to 6. -
FIG. 7 is aflowchart 700 illustrating anexample method 700 for encoding market data. It should be understood that each block in this and subsequent flowcharts may represent a module, segment, or portion of code, which includes one or more executable instructions for implementing specific logical functions or steps in the process. Alternate implementations are included within the scope of the example embodiments in which functions may be executed out of order from that shown or discussed, including substantially concurrently or in reverse order, depending on the functionality involved, as would be understood by those reasonably skilled in the art of the present invention. Theflowchart 700 will be described in relation to the components illustrated inFIG. 2 . However, it should be understood that more, fewer, or different components could also be used to execute themethod 700. - Referring to
FIG. 7 , atstep 702, theencoder 214 encodes a symbol corresponding to a tradeable object with respect to which a change in market data has been detected. It should be understood that each step of encoding inFIG. 7 involves using methods and probability models discussed in relation to the preceding figures. Atstep 704, theencoder 214 encodes a change in the best bid price corresponding to the tradeable object. As explained in relation to preceding figures, encoding a change in the best bid price may include encoding that there has been no change in the best bid price. Atstep 706, theencoder 214 encodes a quantity change corresponding to the best bid. Then, atstep 708, the encoder moves to the next price level on the bid side of the market corresponding to the tradeable object. Atstep 710, theencoder 214 determines if the quantity at the next price level is zero. Then, if the quantity at the next price level is zero, atstep 712, theencoder 214 encodes it as “True,” and moves to the next price level on the bid side of the market, as shown at 708. Referring back to step 710, if the quantity at that price level is not zero, theencoder 214 encodes it as “False,” as shown at 714. Then, since the quantity is not zero, at 716, theencoder 214 can encode the quantity change. - According to one example embodiment, the
exchange 204 may provide a certain number of market depth levels, and, based on that number, theencoder 214 may be programmed to encode and provide a certain number of market depth levels to theclient entity 202. It should be understood that the number of market depth levels to be encoded at theencoder 214 could be the same or lower than that being normally provided from theexchange 204. Also, the number of market depth levels to be encoded by theencoder 214 may be determined by the number of non-zero market depth level, e.g., the market depth levels having non-zero quantity values. Atstep 718, theencoder 214 determines if enough non-zero market depth levels have been already encoded. If not, themethod 700 continues atstep 708. Otherwise, as shown at 720, theencoder 214 proceeds to encoding the ask side of the market corresponding to the tradeable object. According to one example embodiment, theencoder 214 could encode the ask side of the market by following the steps that were used to encode the bid side of the market, which in this example correspond to steps 704-718. - When the
encoder 214 encodes the market depth information, it can also encode other market related parameters. Themethod 700 illustrates the process that can used to encode the last traded price and the last traded quantity. However, it should be understood that different parameters could be encoded using the same or similar methods. Atstep 722, theencoder 214 determines if data related to the last trade has changed. If no changes in the last traded quantity or price have been detected themethod 700 terminates. Otherwise, atstep 724, theencoder 214 encodes the type of the last traded price. The type of the last traded price could be a last bid, a last ask, or yet different types, the examples of which were defined earlier. Then, atstep 726, theencoder 214 determines if the last price type was encoder as “Other.” If so, at 728, theencoder 214 will encode the change in the last traded price. Atstep 730, theencoder 214 may encode the last traded quantity, and themethod 700 terminates. As mentioned earlier, themethod 700 could continue if theencoder 214 is programmed to encode additional market data related parameters. -
FIG. 8 is a flowchart illustrating anexample method 800 for decoding market data. - When the encoded market data is received at the
decoder 224, atstep 802, it may first decode the symbol corresponding to a tradeable object associated with the received data. Similarly to themethod 700, it should be understood that each decoding step described in relation to themethod 800 may involve using the probability models and methods described above. Atstep 804, thedecoder 224 may decode a change in the best bid price. Atsteps decoder 224 decodes a change in the best bid price and the best bid quantity. Atstep 808, thedecoder 224 may move to decoding the next price level. Atstep 810, thedecoder 224 decodes the bit sequence defining if the next price level is zero. Atstep 812, thedecoder 224 determines if the next price level is zero. If it is, atstep 814, it sets the quantity level at that price level to zero, and themethod 800 continues atstep 808. Referring back to step 812, if the price level is not zero, atstep 816, thedecoder 224 decodes a quantity change corresponding to that price level. Atstep 818, thedecoder 224 determines if it has decoded enough non-zero price levels. It should be understood that this number can be preconfigured on the decoder, or it could be provided in relation to the encoded data received from the exchange. If not enough non-zero price levels have been decoded, themethod 800 continues atstep 808. Otherwise the steps described above in relation to decoding the bid side of the market are repeated for the ask side of the market, as shown atstep 820. - Once the
decoder 224 decodes market data corresponding to the bid and ask side of the market, thedecoder 224 may proceed to decoding other market related parameters. Decoding of such parameters will be described in relation to decoding data related to the last trade; however, different parameters could be decoded as well. Atstep 822, thedecoder 224 decodes data defining if the last trade has changed. Atstep 824, based on the decoded data, thedecoder 224 determines if the last trade has changed. If the last trade has not changed, themethod 800 terminates. Otherwise, atstep 826, thedecoder 224 decodes the last traded price type. Then, atstep 828, thedecoder 224 determines if the last traded price type was decoded to be “Other.” If it was not, the method continues atstep 832. If it was, atstep 830, thedecoder 224 decodes the last traded price change. Then, atstep 832, thedecoder 224 decodes the last traded quantity, and themethod 800 terminates. - It will be apparent to those of ordinary skill in the art that methods involved in the system and method for encoding/decoding market data using probability data may be embodied in a computer program product that includes one or more computer readable media. For example, a computer readable medium can include a readable memory device, such as a hard drive device, a CD-ROM, a DVD-ROM, or a computer diskette, having computer readable program code segments stored thereon. The computer readable medium can also include a communications or transmission medium, such as, a bus or a communication link, either optical, wired or wireless having program code segments carried thereon as digital or analog data signals.
- The claims should not be read as limited to the described order or elements unless stated to that effect. Therefore, all embodiments that come within the scope and spirit of the following claims and equivalents thereto are claimed as the invention.
Claims (19)
1. (canceled)
2. A computer readable medium having stored therein instructions executable by a processor, including instructions executable to:
configure by a controller of a compression system of a computing device in communication with an electronic exchange and a client entity a probability model to be associated with a price parameter for a tradeable object, wherein the compression system includes the controller, the probability model, and an encoder, wherein the probability model includes a probability of occurrence of an input symbol associated with the price parameter;
configure by the controller of the compression system of the computing device the probability model to further be associated with a quantity parameter for the tradeable object, wherein the probability model includes a probability of occurrence of an input symbol associated with the quantity parameter;
receive by the compression system of the computing device a price value for the price parameter for the tradeable object, wherein the price value is provided to the compression system of the computing device by the electronic exchange;
receive by the compression system of the computing device a quantity value for the quantity parameter for the tradeable object, wherein the quantity value is provided to the compression system of the computing device by the electronic exchange;
calculate by the compression system of the computing device a price difference, wherein the price difference is a change in value between the price value for the price parameter for the tradeable object and a previous price value for the price parameter for the tradeable object;
calculate by the compression system of the computing device a quantity difference, wherein the quantity difference is a change in value between the quantity value for the quantity parameter for the tradeable object and a previous quantity value for the quantity parameter for the tradeable object;
update by the controller of the compression system of the computing device the probability model associated with the price parameter for the tradeable object based on the calculated price difference;
update by the controller of the compression system of the computing device the probability model associated with the quantity parameter for the tradeable object based on the calculated quantity difference;
encode by the encoder of the compression system of the computing device the calculated price difference using a statistical data encoder to generate an encoded price difference representing the calculated price difference, wherein the calculated price difference is an input symbol to the statistical data encoder, wherein the statistical data encoder is based on the probability model associated with the price parameter for the tradeable object;
encode by the encoder of the compression system of the computing device the calculated quantity difference using the statistical data encoder to generate an encoded quantity difference representing the calculated quantity difference, wherein the calculated quantity difference is an input symbol to the statistical data encoder, wherein the statistical data encoder is based on the probability model associated with the quantity parameter for the tradeable object;
generate by the compression system of the computing device an update message including the encoded price difference and the encoded quantity difference; and
send by the compression system of the computing device the update message to the client entity.
3. The computer readable medium of claim 2 , wherein the price parameter for the tradeable object is a best bid price parameter.
4. The computer readable medium of claim 2 , wherein the price parameter for the tradeable object is a best ask price parameter.
5. The computer readable medium of claim 2 , wherein the price parameter for the tradeable object is a last traded price parameter.
6. The computer readable medium of claim 2 , wherein the probability model includes a plurality of sub-models, wherein a first sub-model of the plurality of sub-models is associated with the price parameter for the tradeable object, wherein updating the probability model includes updating the first sub-model based on the calculated price difference.
7. The computer readable medium of claim 2 , wherein the probability model includes a plurality of sub-models, wherein a first sub-model of the plurality of sub-models is associated with the price parameter for the tradeable object, wherein a second sub-model of the plurality of sub-models is associated with the quantity parameter for the tradeable object.
8. The computer readable medium of claim 7 , wherein updating the probability model associated with the price parameter for the tradeable object includes updating the first sub-model based on the calculated price difference, wherein updating the probability model associated with the quantity parameter for the tradeable object includes updating the second sub-model based on the calculated quantity difference.
9. The computer readable medium of claim 2 , wherein the computing device is part of the electronic exchange.
10. The computer readable medium of claim 2 , wherein the computing device is part of a gateway.
11. A system including:
a computing device,
wherein the computing device is configured to configure by a controller of a compression system of the computing device in communication with an electronic exchange and a client entity a probability model to be associated with a price parameter for a tradeable object, wherein the compression system includes the controller, the probability model, and an encoder, wherein the probability model includes a probability of occurrence of an input symbol associated with the price parameter;
wherein the computing device is configured to configure by the controller of the compression system of the computing device the probability model to further be associated with a quantity parameter for the tradeable object, wherein the probability model includes a probability of occurrence of an input symbol associated with the quantity parameter;
wherein the computing device is configured to receive by the compression system of the computing device a price value for the price parameter for the tradeable object, wherein the price value is provided to the compression system of the computing device by the electronic exchange;
wherein the computing device is configured to receive by the compression system of the computing device a quantity value for the quantity parameter for the tradeable object, wherein the quantity value is provided to the compression system of the computing device by the electronic exchange;
wherein the computing device is configured to calculate by the compression system of the computing device a price difference, wherein the price difference is a change in value between the price value for the price parameter for the tradeable object and a previous price value for the price parameter for the tradeable object;
wherein the computing device is configured to calculate by the compression system of the computing device a quantity difference, wherein the quantity difference is a change in value between the quantity value for the quantity parameter for the tradeable object and a previous quantity value for the quantity parameter for the tradeable object;
wherein the computing device is configured to update by the controller of the compression system of the computing device the probability model associated with the price parameter for the tradeable object based on the calculated price difference;
wherein the computing device is configured to update by the controller of the compression system of the computing device the probability model associated with the quantity parameter for the tradeable object based on the calculated quantity difference;
wherein the computing device is configured to encode by the encoder of the compression system of the computing device the calculated price difference using a statistical data encoder to generate an encoded price difference representing the calculated price difference, wherein the calculated price difference is an input symbol to the statistical data encoder, wherein the statistical data encoder is based on the probability model associated with the price parameter for the tradeable object;
wherein the computing device is configured to encode by the encoder of the compression system of the computing device the calculated quantity difference using the statistical data encoder to generate an encoded quantity difference representing the calculated quantity difference, wherein the calculated quantity difference is an input symbol to the statistical data encoder, wherein the statistical data encoder is based on the probability model associated with the quantity parameter for the tradeable object;
wherein the computing device is configured to generate by the compression system of the computing device an update message including the encoded price difference and the encoded quantity difference; and
wherein the computing device is configured to send by the compression system of the computing device the update message to the client entity.
12. The system of claim 11 , wherein the price parameter for the tradeable object is a best bid price parameter.
13. The system of claim 11 , wherein the price parameter for the tradeable object is a best ask price parameter.
14. The system of claim 11 , wherein the price parameter for the tradeable object is a last traded price parameter.
15. The system of claim 11 , wherein the probability model includes a plurality of sub-models, wherein a first sub-model of the plurality of sub-models is associated with the price parameter for the tradeable object, wherein updating the probability model includes updating the first sub-model based on the calculated price difference.
16. The system of claim 11 , wherein the probability model includes a plurality of sub-models, wherein a first sub-model of the plurality of sub-models is associated with the price parameter for the tradeable object, wherein a second sub-model of the plurality of sub-models is associated with the quantity parameter for the tradeable object.
17. The system of claim 16 , wherein updating the probability model associated with the price parameter for the tradeable object includes updating the first sub-model based on the calculated price difference, wherein updating the probability model associated with the quantity parameter for the tradeable object includes updating the second sub-model based on the calculated quantity difference.
18. The system of claim 11 , wherein the computing device is part of the electronic exchange.
19. The system of claim 11 , wherein the computing device is part of a gateway.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US16/046,415 US20180336632A1 (en) | 2005-03-31 | 2018-07-26 | System and Method for Providing Market Data in an Electronic Trading Environment |
Applications Claiming Priority (6)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/095,100 US7739184B1 (en) | 2005-03-31 | 2005-03-31 | System and method for providing market data in an electronic trading environment |
US12/771,930 US8219482B2 (en) | 2005-03-31 | 2010-04-30 | System and method for providing market data in an electronic trading environment |
US13/491,169 US8473405B2 (en) | 2005-03-31 | 2012-06-07 | System and method for providing market data in an electronic trading environment |
US13/899,835 US8874478B2 (en) | 2005-03-31 | 2013-05-22 | System and method for providing market data in an electronic trading environment |
US14/496,047 US10062116B2 (en) | 2005-03-31 | 2014-09-25 | System and method for providing market data in an electronic trading environment |
US16/046,415 US20180336632A1 (en) | 2005-03-31 | 2018-07-26 | System and Method for Providing Market Data in an Electronic Trading Environment |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/496,047 Continuation US10062116B2 (en) | 2005-03-31 | 2014-09-25 | System and method for providing market data in an electronic trading environment |
Publications (1)
Publication Number | Publication Date |
---|---|
US20180336632A1 true US20180336632A1 (en) | 2018-11-22 |
Family
ID=42244461
Family Applications (6)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/095,100 Expired - Fee Related US7739184B1 (en) | 2005-03-31 | 2005-03-31 | System and method for providing market data in an electronic trading environment |
US12/771,930 Expired - Fee Related US8219482B2 (en) | 2005-03-31 | 2010-04-30 | System and method for providing market data in an electronic trading environment |
US13/491,169 Expired - Fee Related US8473405B2 (en) | 2005-03-31 | 2012-06-07 | System and method for providing market data in an electronic trading environment |
US13/899,835 Expired - Fee Related US8874478B2 (en) | 2005-03-31 | 2013-05-22 | System and method for providing market data in an electronic trading environment |
US14/496,047 Expired - Fee Related US10062116B2 (en) | 2005-03-31 | 2014-09-25 | System and method for providing market data in an electronic trading environment |
US16/046,415 Abandoned US20180336632A1 (en) | 2005-03-31 | 2018-07-26 | System and Method for Providing Market Data in an Electronic Trading Environment |
Family Applications Before (5)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/095,100 Expired - Fee Related US7739184B1 (en) | 2005-03-31 | 2005-03-31 | System and method for providing market data in an electronic trading environment |
US12/771,930 Expired - Fee Related US8219482B2 (en) | 2005-03-31 | 2010-04-30 | System and method for providing market data in an electronic trading environment |
US13/491,169 Expired - Fee Related US8473405B2 (en) | 2005-03-31 | 2012-06-07 | System and method for providing market data in an electronic trading environment |
US13/899,835 Expired - Fee Related US8874478B2 (en) | 2005-03-31 | 2013-05-22 | System and method for providing market data in an electronic trading environment |
US14/496,047 Expired - Fee Related US10062116B2 (en) | 2005-03-31 | 2014-09-25 | System and method for providing market data in an electronic trading environment |
Country Status (1)
Country | Link |
---|---|
US (6) | US7739184B1 (en) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10672075B1 (en) | 2014-12-19 | 2020-06-02 | Data Boiler Technologies LLC | Efficient use of computing resources through transformation and comparison of trade data to musical piece representation and metrical tree |
Families Citing this family (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20100076906A1 (en) * | 2004-07-12 | 2010-03-25 | Rosenthal Collins Group, L.L.C. | Method and system for using quantitative analytics on a graphical user interface for electronic trading |
US7739184B1 (en) | 2005-03-31 | 2010-06-15 | Trading Technologies International, Inc. | System and method for providing market data in an electronic trading environment |
US8364575B2 (en) | 2005-05-04 | 2013-01-29 | Rosenthal Collins Group, Llc | Method and system for providing automatic execution of black box strategies for electronic trading |
US8589280B2 (en) | 2005-05-04 | 2013-11-19 | Rosenthal Collins Group, Llc | Method and system for providing automatic execution of gray box strategies for electronic trading |
US7849000B2 (en) | 2005-11-13 | 2010-12-07 | Rosenthal Collins Group, Llc | Method and system for electronic trading via a yield curve |
TWI346307B (en) * | 2007-03-21 | 2011-08-01 | Telepaq Technology Inc | Method for processing securities data |
KR101401380B1 (en) * | 2010-11-04 | 2014-05-30 | 한국전자통신연구원 | Apparatus for 3d application execution based remote rendering and method thereof |
US10664548B2 (en) * | 2013-07-12 | 2020-05-26 | Trading Technologies International, Inc. | Tailored messaging |
US11315181B2 (en) * | 2014-12-31 | 2022-04-26 | Chicago Mercantile Exchange Inc. | Compression of price data |
US10789542B2 (en) * | 2015-06-05 | 2020-09-29 | Apple Inc. | System and method for predicting changes in network quality |
US20210056634A1 (en) * | 2019-02-04 | 2021-02-25 | Royce Wells | Methods and systems for facilitating modeling of a financial instrument based on a physical model |
CN110457306A (en) * | 2019-08-16 | 2019-11-15 | 中国银行股份有限公司 | Parameterize on line data method for cleaning and device |
US12100048B1 (en) * | 2022-08-31 | 2024-09-24 | Robert D. Arnott | System, method and computer program product for constructing a capitalization-weighted global index portfolio |
Family Cites Families (80)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4112369A (en) * | 1976-04-09 | 1978-09-05 | Digital Data, Inc. | Secure SCA broadcasting system including subscriber actuated portable receiving terminals |
US4196310A (en) * | 1976-04-09 | 1980-04-01 | Digital Data, Inc. | Secure SCA broadcasting system including subscriber actuated portable receiving terminals |
JPH0219963A (en) * | 1988-07-08 | 1990-01-23 | Hitachi Ltd | Method and system for monitoring real time state |
US5101353A (en) * | 1989-05-31 | 1992-03-31 | Lattice Investments, Inc. | Automated system for providing liquidity to securities markets |
US6505174B1 (en) * | 1996-03-25 | 2003-01-07 | Hsx, Inc. | Computer-implemented securities trading system with a virtual specialist function |
EP0912954B8 (en) * | 1996-07-22 | 2006-06-14 | Cyva Research Corporation | Personal information security and exchange tool |
US6100824A (en) * | 1998-04-06 | 2000-08-08 | National Dispatch Center, Inc. | System and method for data compression |
US7539637B2 (en) * | 1998-04-24 | 2009-05-26 | Starmine Corporation | Security analyst estimates performance viewing system and method |
US6493682B1 (en) * | 1998-09-15 | 2002-12-10 | Pendelton Trading Systems, Inc. | Optimal order choice: evaluating uncertain discounted trading alternatives |
US6205431B1 (en) * | 1998-10-29 | 2001-03-20 | Smart Software, Inc. | System and method for forecasting intermittent demand |
US7966078B2 (en) * | 1999-02-01 | 2011-06-21 | Steven Hoffberg | Network media appliance system and method |
US7082410B1 (en) * | 1999-07-02 | 2006-07-25 | The Nasdaq Stock Market, Inc. | Line handler |
US7225174B2 (en) * | 1999-07-14 | 2007-05-29 | Hewlett-Packard Development Company, L.P. | Investment analysis tool and service for making investment decisions |
US8577778B2 (en) * | 1999-07-21 | 2013-11-05 | Longitude Llc | Derivatives having demand-based, adjustable returns, and trading exchange therefor |
US7996296B2 (en) * | 1999-07-21 | 2011-08-09 | Longitude Llc | Digital options having demand-based, adjustable returns, and trading exchange therefor |
US6321212B1 (en) * | 1999-07-21 | 2001-11-20 | Longitude, Inc. | Financial products having a demand-based, adjustable return, and trading exchange therefor |
US6912511B1 (en) * | 1999-08-19 | 2005-06-28 | David A. Eliezer | Method of monitoring market liquidity |
EP1178416A1 (en) * | 1999-08-27 | 2002-02-06 | Kabushiki Kaisha Toshiba | System for evaluating price risk of financial product or its financial derivative, dealing system, and recorded medium |
US7181424B1 (en) * | 1999-09-23 | 2007-02-20 | The Nasdaq Stock Market, Inc. | Montage for automated market system |
US20070027787A1 (en) * | 1999-10-06 | 2007-02-01 | Tripp Thomas W | Software system for real monetary instruments |
US6876981B1 (en) * | 1999-10-26 | 2005-04-05 | Philippe E. Berckmans | Method and system for analyzing and comparing financial investments |
CA2290888A1 (en) * | 1999-11-26 | 2001-05-26 | Algorithmics International Corp. | Risk management, pricing and portfolio makeup system and method |
JP3307909B2 (en) * | 2000-01-24 | 2002-07-29 | ケンテックス株式会社 | Method of compressing stock price data and method of compressing and sending stock price data |
US20060020530A1 (en) * | 2000-02-14 | 2006-01-26 | Hsu Phillip K | Systems for providing financial services |
US7171384B1 (en) * | 2000-02-14 | 2007-01-30 | Ubs Financial Services, Inc. | Browser interface and network based financial service system |
US7389268B1 (en) | 2000-03-02 | 2008-06-17 | Trading Technologies International, Inc. | Trading tools for electronic trading |
US6772132B1 (en) | 2000-03-02 | 2004-08-03 | Trading Technologies International, Inc. | Click based trading with intuitive grid display of market depth |
US7127424B2 (en) | 2000-03-02 | 2006-10-24 | Trading Technologies International, Inc. | Click based trading with intuitive grid display of market depth and price consolidation |
US6392567B2 (en) * | 2000-03-31 | 2002-05-21 | Fijitsu Limited | Apparatus for repeatedly compressing a data string and a method thereof |
US6963855B1 (en) * | 2000-04-10 | 2005-11-08 | Alexander Borzenko | Apparatus and method for automated display of market activity |
US7742959B2 (en) * | 2000-05-01 | 2010-06-22 | Mueller Ulrich A | Filtering of high frequency time series data |
US20030149648A1 (en) * | 2000-05-01 | 2003-08-07 | Olsen Richard B. | Method and system for measuring market conditions |
US7702548B2 (en) * | 2000-05-01 | 2010-04-20 | Zumbach Gilles O | Methods for analysis of financial markets |
US7343308B1 (en) * | 2000-05-26 | 2008-03-11 | Hartford Fire Insurance Compnay | Method and system for identifying subrogation potential and valuing a subrogation file |
US7685052B2 (en) * | 2000-06-01 | 2010-03-23 | Pipeline Financial Group, Inc. | Confidential block trading system and method |
US8010438B2 (en) * | 2000-06-01 | 2011-08-30 | Pipeline Financial Group, Inc. | Method for directing and executing certified trading interests |
US20010056395A1 (en) * | 2000-06-09 | 2001-12-27 | Khan Saadat H. | Internet bargaining system |
US7236953B1 (en) * | 2000-08-18 | 2007-06-26 | Athena Capital Advisors, Inc. | Deriving a probability distribution of a value of an asset at a future time |
US7689498B2 (en) * | 2000-08-24 | 2010-03-30 | Volbroker Limited | System and method for trading options |
US6961685B2 (en) * | 2000-09-19 | 2005-11-01 | Sy Bon K | Probability model selection using information-theoretic optimization criterion |
US7417568B2 (en) * | 2000-10-03 | 2008-08-26 | Realtime Data Llc | System and method for data feed acceleration and encryption |
US7080117B2 (en) * | 2000-11-17 | 2006-07-18 | Robert dePinto | System and method for exchanging creative content |
US7212998B1 (en) * | 2000-11-21 | 2007-05-01 | Olsen Data Ltd. | Method for creating and pricing options |
US7020630B2 (en) * | 2000-12-01 | 2006-03-28 | John Russell | Computer assisted securities trading |
US7167837B1 (en) * | 2001-04-16 | 2007-01-23 | Ft Interactive Data Corporation | Fair-value pricing of a financial asset |
US7702563B2 (en) * | 2001-06-11 | 2010-04-20 | Otc Online Partners | Integrated electronic exchange of structured contracts with dynamic risk-based transaction permissioning |
US20030009419A1 (en) * | 2001-06-11 | 2003-01-09 | Chavez R. Martin | Risk management system and trade engine with automatic trade feed and market data feed |
EP1412835A4 (en) * | 2001-07-31 | 2004-08-18 | American Express Travel Relate | System and method for providing financial planning and advice--- |
US20030061152A1 (en) * | 2001-09-26 | 2003-03-27 | De Rabi S. | System and method for determining Value-at-Risk using FORM/SORM |
EP1444617A4 (en) * | 2001-10-13 | 2005-11-02 | Superderivatives Inc | Method and system for pricing financial derivatives |
US8611919B2 (en) * | 2002-05-23 | 2013-12-17 | Wounder Gmbh., Llc | System, method, and computer program product for providing location based services and mobile e-commerce |
US20060100949A1 (en) * | 2003-01-10 | 2006-05-11 | Whaley Robert E | Financial indexes and instruments based thereon |
WO2003107121A2 (en) * | 2002-06-18 | 2003-12-24 | Tradegraph, Llc | System and method for analyzing and displaying security trade transactions |
CN1675643A (en) * | 2002-06-18 | 2005-09-28 | 孔特奇·菲尔 | Method, system and computer program for facilitating derivative instrument contract generation and trading |
US7797215B1 (en) * | 2002-06-26 | 2010-09-14 | Power Financial Group, Inc. | System and method for analyzing and searching financial instrument data |
JP4029934B2 (en) * | 2003-07-24 | 2008-01-09 | インターナショナル・ビジネス・マシーンズ・コーポレーション | Distributed computing system |
US7769668B2 (en) * | 2002-12-09 | 2010-08-03 | Sam Balabon | System and method for facilitating trading of financial instruments |
US20040128261A1 (en) * | 2002-12-31 | 2004-07-01 | Thomas Olavson | Method and system for creating a price forecasting tool |
US20040148248A1 (en) * | 2003-01-03 | 2004-07-29 | Allen Laurence G. | Secondary transfers of restricted interests |
US7680722B2 (en) * | 2003-03-03 | 2010-03-16 | Itg Software Solutions, Inc. | Dynamic aggressive/passive pegged trading |
US20050004862A1 (en) * | 2003-05-13 | 2005-01-06 | Dale Kirkland | Identifying the probability of violative behavior in a market |
US7725374B2 (en) * | 2003-10-10 | 2010-05-25 | Julian Van Erlach | Asset analysis according to the required yield method |
US20050080710A1 (en) * | 2003-10-14 | 2005-04-14 | Malato Richard A. | Method and apparatus for providing trading information |
US20050108148A1 (en) * | 2003-11-17 | 2005-05-19 | Charles Carlson | System and method of investing in a market |
US20060136318A1 (en) * | 2004-01-21 | 2006-06-22 | Lava Trading Inc. | Automated system for routing orders for financial instruments |
US7788158B2 (en) * | 2004-02-03 | 2010-08-31 | Yahoo! Inc. | Dynamic pari-mutuel market |
EP1738321A4 (en) * | 2004-04-01 | 2009-01-21 | Waverules Llc | Systems and methods of electronic trading using automatic book updates |
US7970690B2 (en) * | 2004-08-19 | 2011-06-28 | Leadpoint, Inc. | System for implementing automated open market auctioning of leads |
AU2005277150B2 (en) * | 2004-08-21 | 2011-05-26 | Directworks, Inc. | Methods, systems, and apparatuses for extended enterprise commerce |
US7885884B2 (en) * | 2004-08-26 | 2011-02-08 | Barclays Capital, Inc. | Methods and systems for interest rate prediction |
US7590589B2 (en) * | 2004-09-10 | 2009-09-15 | Hoffberg Steven M | Game theoretic prioritization scheme for mobile ad hoc networks permitting hierarchal deference |
US20060106708A1 (en) * | 2004-11-18 | 2006-05-18 | Abushaban Bassel M | System and method for processing matched trades |
US7783544B2 (en) * | 2004-12-21 | 2010-08-24 | Weather Risk Solutions, Llc | Financial activity concerning tropical weather events |
US8639629B1 (en) * | 2005-02-02 | 2014-01-28 | Nexus Payments, LLC | System and method for accessing an online user account registry via a thin-client unique user code |
US20060195391A1 (en) * | 2005-02-28 | 2006-08-31 | Stanelle Evan J | Modeling loss in a term structured financial portfolio |
US7739184B1 (en) | 2005-03-31 | 2010-06-15 | Trading Technologies International, Inc. | System and method for providing market data in an electronic trading environment |
US20070162365A1 (en) * | 2005-07-27 | 2007-07-12 | Weinreb Earl J | Securities aid |
US20070038579A1 (en) * | 2005-08-12 | 2007-02-15 | Tsys-Prepaid, Inc. | System and method using order preserving hash |
US20070106593A1 (en) * | 2005-11-07 | 2007-05-10 | Grant Lin | Adaptive stochastic transaction system |
US9940670B2 (en) * | 2009-12-10 | 2018-04-10 | Royal Bank Of Canada | Synchronized processing of data by networked computing resources |
-
2005
- 2005-03-31 US US11/095,100 patent/US7739184B1/en not_active Expired - Fee Related
-
2010
- 2010-04-30 US US12/771,930 patent/US8219482B2/en not_active Expired - Fee Related
-
2012
- 2012-06-07 US US13/491,169 patent/US8473405B2/en not_active Expired - Fee Related
-
2013
- 2013-05-22 US US13/899,835 patent/US8874478B2/en not_active Expired - Fee Related
-
2014
- 2014-09-25 US US14/496,047 patent/US10062116B2/en not_active Expired - Fee Related
-
2018
- 2018-07-26 US US16/046,415 patent/US20180336632A1/en not_active Abandoned
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10672075B1 (en) | 2014-12-19 | 2020-06-02 | Data Boiler Technologies LLC | Efficient use of computing resources through transformation and comparison of trade data to musical piece representation and metrical tree |
Also Published As
Publication number | Publication date |
---|---|
US8874478B2 (en) | 2014-10-28 |
US10062116B2 (en) | 2018-08-28 |
US20140143112A1 (en) | 2014-05-22 |
US20150142635A1 (en) | 2015-05-21 |
US8219482B2 (en) | 2012-07-10 |
US7739184B1 (en) | 2010-06-15 |
US20100211529A1 (en) | 2010-08-19 |
US20120246057A1 (en) | 2012-09-27 |
US8473405B2 (en) | 2013-06-25 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20180336632A1 (en) | System and Method for Providing Market Data in an Electronic Trading Environment | |
US11562431B2 (en) | System and method for providing market updates in an electronic trading environment | |
US9501797B2 (en) | System and method for providing electronic price feeds for tradeable objects | |
US8041622B1 (en) | System and method for randomizing orders in an electronic trading environment | |
WO2003017062A2 (en) | Securities quotation display method and system | |
US20040254876A1 (en) | Schemes for simulating a financial market | |
US20050055301A1 (en) | Systems and methods for computing performance parameters of securities portfolios | |
AU2011204976B2 (en) | System and method for providing electronic price feeds for tradeable objects |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: TRADING TECHNOLOGIES INTERNATIONAL, INC., ILLINOIS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:NERI, MARK;REEL/FRAME:046471/0556 Effective date: 20050330 |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |