Patent Publication Number: US-7917418-B2

Title: Efficient data dissemination for financial instruments

Description:
BACKGROUND 
     Market centers within some financial sectors, such as the equity, equity option and commodity markets, cooperate by adopting common message formats and dissemination rules for trade-related data. In some sectors, participating market centers have established a single entity or organization to consolidate all of their outbound market data streams, giving market data recipients a single source for all of the marketplace&#39;s real-time data. For example, the Options Price Reporting Authority (OPRA) was established by participating equity option market centers to receive and consolidate their several feeds into one, then disseminate the consolidated market data to subscribed market data recipients. 
     However, the volume of data disseminated by individual market centers continues to grow, putting down-stream consolidation systems, such as OPRA, at increasing risk of being overwhelmed. Participating market centers can generate vast amounts of data and disseminate it at high rates. Presently, market data systems typically disseminate all data on all listed instruments, regardless of whether a given instrument has seen recent market activity. Potentially, any one market center disseminating at a high data throughput rate might overwhelm the down-stream consolidation system. This can disadvantage all of the market centers by monopolizing the consolidator&#39;s data processing resources, possibly causing delays in the data being sent by the consolidator to downstream recipients. Any delay in downstream data is viewed as a very serious problem by market centers and consolidators, since even the smallest data delays degrade the data and pose a threat to investors. To reduce the risk of market centers flooding the consolidation systems, market centers often agree to individual thresholds on the amount of data they can disseminate to the consolidation entity. Any such thresholds are referred to herein as throughput limits. 
     In order to discourage market centers from exceeding their throughput limits, penalties are typically imposed, such as fines levied against the offending market center. Data consolidators, such as OPRA, typically have the additional power to address excessive throughput rates in real-time by physically throttling the offending market center&#39;s data stream. This throttling ability helps the data consolidator protect against data processing delays by bringing the offending market center&#39;s dissemination rate back under its assigned threshold. Conversely, because a market center can be enormously disadvantaged if it cannot disseminate all of its trade-related market data in real time to the consolidator, there is a constant tension between the market center&#39;s need to disseminate all real-time trade related data, and the need to protect downstream systems from being flooded. 
     Accordingly, there is need for a method and system that reduces the overall volume of data disseminated to a data consolidation entity without degrading the high quality real-time data disseminated to the data consolidation entity. 
     SUMMARY 
     According to one aspect of the present invention, a method for suppressing non-pertinent market data from being reported by a market center throughout the financial marketplace includes providing a market center having a plurality of financial instruments listed thereon, wherein each listed financial instrument has at least one record associated with it which includes pricing information for the listed financial instrument. Further, according to this aspect of the invention, the market center reports the pricing information throughout the financial marketplace. 
     According to this aspect of the present invention, the method monitors the trading activity of the plurality of financial instruments listed on the market center throughout the financial marketplace and flags the records for a listed financial instrument for reporting suppression when the financial instrument has not traded within a pre-determined time period in the financial marketplace. 
     The method, according to this aspect of the present invention, suppresses information on the flagged listed financial instruments when the market center reports pricing information throughout the financial marketplace. 
    
    
     
       DESCRIPTION OF THE DRAWINGS 
       These and other features, aspects and advantages of the present invention will become better understood with regard to the following description, appended claims and accompanying drawings where: 
         FIG. 1  is a block diagram illustrating the data dissemination environment in which an embodiment of the present invention operates; 
         FIG. 2  is a flow diagram illustrating a process implemented in an embodiment of the present invention to set the reporting status of an instrument listed on a reporting market center; 
         FIG. 3  is a flow diagram illustrating a process implemented in an embodiment of the present invention to determine what quote or order information is reported out from a reporting market center; and 
         FIG. 4  depicts an exemplary depth of book data structure and a top of book data structure. 
     
    
    
     DETAILED DESCRIPTION 
     Referring to  FIG. 1 , an exemplary reporting market center  20 , in an active market environment, is depicted. The examples discussed herein primarily describe the use and application of the present invention in an equity options market center environment, but it should be understood that the present invention could be used in any type of financial instrument market center environment (e.g., equities, futures, bonds, etc.). The market environment of this embodiment includes a reporting market center  20  which interacts with a number of other market centers  24  (i.e., away markets), traders at order sending firms  26  and market makers  31 . It should be understood that the trading environment of this embodiment supports but does not require market makers  31 , a market maker interface  32 , or market maker quotes  33 . It should also be understood that the reporting market center  20  referred to herein refers to a computing system having sufficient processing and memory capabilities and does not refer to a specific physical location. In fact, in certain embodiments, the computing system may be distributed over several physical locations. It should also be understood that any number of traders  26  or market makers  31  or away market centers  24  can interact with the reporting market center  20 . The reporting market center  20  is the market center on which a specific trader at an order sending firm  26  posts a specific order, and on which a specific market maker  31  posts a specific quote, and those orders and quotes, and trades resulting therefrom, are reported out. The reporting market center  20  includes an order matching engine  21 , which validates, maintains, matches and processes all orders and quotes on the reporting market center  20 . In this embodiment, the code for the order matching engine  21  is stored in the reporting market center&#39;s fixed storage media and loaded into system memory at run time. 
     The reporting market center  20  may also include a quote and last sale interface  23  that, in this embodiment, interacts with a data consolidator  40  to capture quote and last sale information. This quote and last sale information is stored in a best bids and offers and last sales data structure  25 . This data structure  25  is where the market best bid and offer information is stored. Because the quote and last sale interface  23  receives every trade record for each instrument across all market centers, including the given reporting center  20  and all participating away market centers  24 , it has a record of the last date every listed instrument traded, regardless of which market center  20 ,  24  executed the trade. The last date an instrument traded is referred to as “last trade date” herein. The reporting market center  20  may also include a quote server  42  which monitors the trading activity of instruments listed on the market center  20  and updates the trading parameters of a listed instrument on an order and trade parameters data structure  27 , included within the reporting market center  20 . 
     The order and trade parameters data structure  27  stores pre-defined trading parameters and rules that are used by the order matching engine  21  in reporting orders, matching orders and executing trades. The reporting market center  20  may also include an order and execution interface  28  which allows the traders  26 , the market makers  31  and the away market centers  24  to interact with the market center  20 . The order and execution interface  28  also interacts with the order matching engine  21  in the order execution process. The reporting market center  20  may also include an order information data structure  29  where order information is stored and a trade information data structure  30  where completed trade information is stored. The reporting market center  20  may also include a market maker interface  32  that interacts with market makers  31  to capture market maker bids and offers in assigned issues. These bids and offers are tracked and stored in a market maker quotes structure  33  in this embodiment. In another embodiment, the market maker bids and offers may physically reside in the away market center best bids and offers data structure  25 . 
     Throughout the discussion herein, it should be understood that the details regarding the operating environment, data structures, and other technological elements surrounding the reporting market center  20  are by way of example and that the present invention may be implemented in various differing forms. For example, the data structures referred to herein may be implemented using any appropriate structure, data storage, or retrieval methodology (e.g., local or remote data storage in data bases, tables, internal arrays, etc.). Furthermore, a market center of the type described herein may support any type of suitable interface on any suitable computer system. 
     The reporting market center  20  of this embodiment may also include an aggregator  34 . The aggregator  34  is passed incoming quotation and order data from the order matching engine  21 . The aggregator  34 , in turn, reads this incoming quotation and order data and consolidates the best price and aggregate volume for each instrument. Ultimately, in this embodiment, the aggregator  34  disseminates two types of aggregated records to market data subscribers  38   a - d ,  43   a - d . One such multicast data dissemination feed is the “top of book” feed  39   a , which includes only the best prices (along with the aggregate volumes) for each instrument, while the other feed  39   b , the “depth of book” feed, carries the top five best prices (and respective aggregate volumes) for each instrument. 
     In this embodiment, only the best price or “top of book” data is sent to the common data consolidator  40 . In this embodiment, the market center system component responsible for such dissemination is referred to as the data consolidator server  36 . In the preferred embodiment of the invention, the data consolidator server  36  receives the top of book multicast dissemination  39   a  generated by the aggregator  34 . However, it should be noted that in other embodiments of the present invention, the data may be disseminated using any suitable communications methodology without affecting the nature of the invention. The top of book data is immediately disseminated by the data consolidator server  36  to the data consolidator  40 . 
     At the same time that the data consolidator  40  is receiving the top of book data from the market center  20 , the data consolidator  40  is also simultaneously receiving top of book data from all other participating market centers  24  (i.e., away markets). The data consolidator  40  consolidates the many feeds into one feed and disseminates the consolidated data stream to all data consolidator subscribers  44   a - d . In this embodiment, the market center  20  depicted is also a data consolidator subscriber, with the data consolidator  40  sending the data consolidation feed to the quote and last sale interface  23  of the reporting market center  20 . 
     Referring to  FIG. 2 , the process, in a preferred embodiment, for setting which instruments the market center  20  reports on and does not report on is illustrated. As indicated at step  240 , the system initializes at the start of a trading session. As part of the initialization, the quote server  42  retrieves the last trade date for every individual instrument listed within the market center  20  from the quote and last sale interface  23  as indicated at step  242 . Then, in this embodiment, at step  248 , for every instrument, the process identifies whether or not a given instrument has traded within the past ten (10) days. By doing this for each instrument, the process determines which instruments have not traded (or have been inactive) in recent trading and, therefore, determines that there is limited to no market interest in them. As such, these instruments do not need to be reported out and reporting bandwidth can be saved. It should be understood that the number of days of inactivity is not limited to ten (10) days and that any number of days of inactivity could be used as a trigger point (e.g., 3 days, 4 days, etc.). 
     If, at step  248 , the process determines that the instrument under evaluation has traded recently (i.e., has traded within the last ten (10) days), a trading activity flag  146  ( FIG. 4 ), stored in the order and trade parameters data structure  27 , for the instrument under evaluation is flagged as “false,” as indicated at step  250 , and is reported out as explained in detail below. If, on the other hand, at step  248 , the process determines that the instrument under evaluation has not traded recently (i.e., has not traded within the last ten (10) days), the flag  146  for the instrument under evaluation is set to “true,” as indicated at step  252  and depicted for record  108   a  in  FIG. 4 . An instrument with the flag  146  set to “true” is referred to as an instrument with a “dark flag” herein. In this invention, order and quotation data for an instrument with a “dark flag” is suppressed and not sent to the data consolidator  40 , since the marketplace does not have enough interest in this instrument to justify using the limited bandwidth to report on it. As indicated at step  254 , this process continues until every instrument listed on the market center  20  is evaluated. As indicated in  FIG. 2 , the flag for every instrument is evaluated and set prior to the start of trading. Regarding  FIG. 4 , it should be noted that in the present implementation of this invention, the depth of book  100  and top of book  156  data is physically stored in one data structure. However, for illustrative purposes, the data is depicted in  FIG. 4  and referred to herein as though it were stored in separate data structures. 
     As indicated at steps  256  and  258 , trading starts, and the order matching engine  21  begins, and continues throughout the trading session, to execute trades and maintain orders and quotes. During the trading session, as indicated at step  260 , the quote and last sale interface  23  continuously receives and stores the consolidated market data feed messages from the data consolidator  40  to the data structure  25 . Since the consolidated feed disseminates every trade record that occurs for every instrument at every participating market center  20 ,  24 , the quote and last sale interface  23  is assured of having a fully comprehensive set of last trade date information for every instrument. As part of this process, the quote and last sale interface  23  updates the “last trade date” information for each instrument listed on the market center  20 . At step  264 , the quote server  42  receives quote and last sale records from the quote and last sale interface  23 . For every last sale record, the quote server  42  updates the trading activity flag  146  setting for the given instrument to “false” within the order and trade parameter data structure  27 . By doing this, the process ensures any instrument that trades (or has been active) has its trading activity flag  146  set to “false,” indicating recent activity. 
     If a given instrument has traded during the trading session, the trading activity flag  146  for the instrument under evaluation is automatically set to “false”. In other words, if the flag was previously “false,” it will remain set to “false” and data will continue to be reported out. If the flag was previously “true”, it is reset to “false,” and going forward, until this instrument is inactive for the required amount of time, all data is reported out. If, on the other hand, a “dark” instrument has not traded during the trading session, the flag  146  for the instrument will never be automatically overwritten and the flag  146  remains set to “true.” As indicated at step  272 , this process continues throughout the trading session until the last record of the session is reached. At that point, the end of trading session processing is invoked as indicated at step  274 . 
     It should be understood that if a market participant has an interest in a listed instrument that has a “dark flag” on it, the “dark flag” may be manually overridden so that it will be reported on during the given trading session. This override can be effectuated by manually changing the instrument&#39;s “dark flag” from “true” to “false” within the order and trade parameters data structure itself  27 . In this embodiment, however, unless a trade occurs in the manually-overridden listed instrument during the trading session that the override is in place, the trading activity flag  146  will automatically be re-set to “true” (i.e., the “dark flag” will be reinstated) at the start of the next trading session when systems are initialized  240 . The information for this instrument will once again be suppressed, unless manually overridden again in the new trading session. 
     During the trading session, while the quote server  42  is monitoring all markets (via the Data Consolidator  4 )) for trading activity in the instruments listed on the reporting market center  20  and updating the instruments&#39; records accordingly, the aggregator  34  is consolidating order and quote information and reporting it out. Referring now to  FIG. 3 , the process for reporting out from the reporting market center  20  is illustrated, and  FIG. 4  illustrates exemplary depth of book and top of book data structures  100 ,  156 . As mentioned previously, the depth of book  100  and top of book  156  data structures may be maintained as a single structure or as multiple structures without impacting the present invention. Two structures are illustrated here for clarity. At step  282 , the aggregator  34  receives quotation and order message information from the matching engine  21 . At step  286 , the aggregator  34  starts the process of comparing the received bid or offer price information to the best bids and offers in the book. At step  286 , the process determines whether the price of the incoming order or quote is equal to or better than the top five best bids or offers in the book. If at step  286 , the process determines that the price of the incoming order or quote is equal to or better than the top five prices for the given instrument, then it qualifies to be reported out as depth of book data  39   b , and the process proceeds to step  290 . If, on the other hand, it is determined that the price of the incoming order or quote is not equal to or better than the top five best prices, then the price is not reported out, and the process, for this order or quote message, ends as indicated at  288 . 
     At step  290 , the process determines if the incoming price of the order or quote message is equal to an existing depth of book price. If the incoming price is equal to an existing depth of book price, the aggregator  34 , at step  292 , adds the volume for the incoming order or quote to the existing volume record for the given instrument at that price level to obtain an aggregate total volume. Then at step  296 , the aggregator  34  disseminates the now updated record information to the depth of book multicast  39   b . An exemplary depth of book data structure  100  is depicted in  FIG. 4 . 
     If, on the other hand, at step  290  the process determines that the incoming price is within the top five best prices, but does not match any existing price, the aggregator  34 , as indicated at step  294 , must create a new price level record for the given instrument, insert it into the appropriate place within the top five depth of book prices and remove a price record that has been displaced because it is no longer in the top five. At step  296 , the process disseminates the now updated record information to the depth of book multicast  39   b . In this embodiment, it should be noted that depth of book record information is disseminated without regard to whether the instruments that are being reported on have recently traded. In other embodiments, however, this may be changed by implementing the invention disclosed and described herein for depth of book data. 
     If an incoming price also happens to be to be the best bid or best offer for a given instrument, then the incoming order or quote may also have to be disseminated in the top of book multicast feed  39   a . An exemplary top of book data structure  156  is depicted in  FIG. 4 . To determine if the incoming order or quote needs to be disseminated in the top of book multicast  39   a , the process, at step  298 , determines if the incoming price is at price level  1  in the depth of book data structure  100 . If it is not, the incoming order or quote is not disseminated in the top of book multicast  39   a , as indicated at  300 . If, on the other hand, the incoming price is at price level  1 , the process proceeds to step  302  where it accesses the order and trade parameter data structure  27  to determine whether the trading activity flag  146  for the instrument under evaluation is set to “true” or “false”. If the flag  146  is set to “false” (meaning the instrument under evaluation has had recent trading activity), then the incoming order or quote is reported in the top of book multicast  39   a , as indicated at  306 . If, on the other hand, the flag  146  is set to “true” or has a “dark flag” (meaning the instrument under evaluation has not had recent trading activity), then the incoming order or quote is not reported in the top of book multicast  39   a , as indicated at  304 . 
     Referring to step  308 , orders and quotes that are not “dark” and are included in the top of book multicast  39   a  are received by the data consolidator server  36  which sends them to the data consolidator  40 , where the order or quotes are added to the consolidated market data feed. As indicated at step  310 , the aggregator  34  continues processing orders and quote messages until the end of the trading session, and at the end of the trading session, as indicated at  312 , the aggregator  34  executes end of trading session processing. 
     Referring to  FIG. 4 , it can be seen that, in this illustration, depth of book and top of book data structures  100 ,  156  share most of the same basic data fields for each instrument because the data in the top of book data structure  156  is a subset of the data contained in the depth of book data  100 . It should be understood that the depictions provided are simplified, exemplary representations for illustration purposes of the actual data contained in these types of messages, and only the fundamental data common to both are discussed herein. Both types of records have product or listed instrument data  134   a ,  134   b ; best bid data  138   a ,  138   b ; bid volume data  140   a ,  140   b ; best ask data  142   a ,  142   b  and ask volume data  144   a ,  144   b . As explained below, only the depth of book records  100  require price level indicators  136   a , and as explained above, in this embodiment, only the top of book records  156  require trading activity flags  146 . The data illustrated in the depth of book data structure  100  is required to be more expansive, providing several layers of best prices, with aggregated volumes at each level for each instrument. The top of book data  156 , as its name states, only includes the market information for bids and offers at the top of the book. 
     In this embodiment, only top of book data is reported out to the data consolidator  40 . As such, the trading activity flag  146  is only required for top of book data  156 . The data illustrated in the depth of book data structure  100  does not need to be limited for reporting purposes with a trading activity flag in this embodiment. The depth of book data  100 , in this embodiment, contains multiple records (e.g.,  104   a - e ,  106   a - e ,  108   a ,  110   a ,  116   a , etc.). As is apparent, in the depth of book data structure  100 , a listed instrument may have multiple records, such as the data records for listed instrument ABC AA (i.e., records  104   a - e ). The various records for the product are distinguished by the price level indicator  136   a , which shows the best price for the product, the next best price, and so on, through five levels of pricing. Referring to the record indicated at  106   a  for ABC AB ( 173 ), for example, the best prices for this instrument are a bid of 6 at price level “ 1 ”, as indicated at  176  and  174  respectively, with an aggregated total of 100 shares, as indicated at  178 , and an ask of 8, as indicated at  180 , with an aggregated total of 200 shares, as indicated at  182 . In this example, for instrument ABC AB, this information means that, at the present moment in time, the most anyone is willing to pay for the instrument is $6 and the most anyone is willing to sell the instrument for is $8. The next best prices and the respective volumes for the same instrument are depicted in the next row at  106   b.    
     In contrast to the data in the depth of book data structure  100 , the data in the top of book data structure  156  is only for the best bid  138   b  and the best offer  142   b  (and their associated volumes  140   b ,  144   b ) for each instrument, making the ranking of price level information moot and explaining why the top of book data structure  156  does not require a price level parameter comparable to the one found in the depth of book data structure  100 . As explained above, the data illustrated in the top of book data structure  156  is simply a subset of the data from the depth of book data structure  100 . Namely, the data in the top of book data structure  156  is the same as the data records at price level “ 1 ” in the depth of book data structure  100 . The records at the price level “ 1 ” in the depth of book data structure  100  map directly to the same instrument&#39;s record in the top of book data structure  156 , as indicated at  148 ,  150 ,  152 ,  154  and  155 . In this example, it can be seen at  183  and  184  that listed instruments ABC AA and ABC AB do not have a dark flag and are reported out in the top of book multicast  39   a . Listed instruments ABC AC, ABC AD and XYZ AA, on the other hand, have the trading activity flag  146  set to “true,” as indicated at  186 ,  188  and  190 , meaning they have a “dark flag.” The information for these listed instruments, accordingly, is not reported out. 
     While the invention has been discussed in terms of certain embodiments, it should be appreciated that the invention is not so limited. The embodiments are explained herein by way of example, and there are numerous modifications, variations and other embodiments that may be employed that would still be within the scope of the present invention.