Patent Publication Number: US-7912775-B1

Title: Liquidity analysis system and method

Description:
BACKGROUND 
     Liquidity, in one sense, refers to how easily one can get into or out of an investment in a financial instrument (e.g., securities, futures contracts, options, bonds, etc.). In an illiquid market, sellers cannot easily find buyers. When that happens, investment risk can be high because sellers cannot get their money out of their investments easily. A liquid market also tends to have better price stability and increased overall order volume because issuers, investors and market participants typically seek out the most liquid marketplaces. 
     As a result, market centers, such as securities exchanges, try to make the most liquid market possible. One way market centers attempt to generate market liquidity is through market makers. Market makers are firms or individuals who “make markets” in a financial instrument by quoting the prices at which they are willing to buy or sell that financial instrument. These price quotes—bids and offers (or “bids and asks”)—are published to the investing community via the various data feeds put out by the market centers where the given market makers operate. When investors or their agents check the price quotes and decide to make a trade, the market maker for that security will generally guarantee to buy or sell at least some of the shares at the published price. Because market makers are willing to take on risk themselves and follow through on published bid or ask prices, they can provide liquidity to the marketplace. 
     The key to a market maker&#39;s ability to generate liquidity and bring these benefits to the marketplace is its ability to make effective quotes and trades. Every market center&#39;s goal, and as such every market maker for that market center&#39;s goal, is to post the highest bid and lowest offer (e.g., the “inside” market) in the entire marketplace so they can consistently execute orders and provide the most liquidity. At any given moment, the best price across all market centers is the market best bid (“Market Best Bid”) or market best offer (“Market Best Offer”). Therefore, every market center, and every market maker associated with that market center, wants to be setting the Market Best Bid and Market Best Offer (or trading very near those prices) as often as possible. 
     Though every market center and market maker wants to be at the Market Best Bid and Market Best Offer, there is presently no effective way for a market center, a market maker or an investor to assess how often a market center, a market maker or any other market participant is at the inside market and, therefore, no effective way to gauge a market center&#39;s liquidity or market maker&#39;s ability to generate liquidity in a market. 
     Accordingly, there is a need for a market liquidity analysis system and method that allows interested persons to monitor, collect and analyze a market center&#39;s, a market maker&#39;s or any market participant&#39;s trading activity to measure liquidity or to assess such entity&#39;s or individual&#39;s role in generating liquidity. 
     SUMMARY 
     According to one aspect of the present invention, a method for analyzing market center liquidity includes monitoring orders and quotes for a specified financial instrument for a specific market participant and analyzing the orders and quotes made by the specified market participant in the specified financial instrument and determining a best price for the market participant at a certain time. It further includes retrieving the market best price for the specified financial instrument for the same time and comparing the best price determined for the market participant at the certain time to the market best price for the same time. It further includes recording the results of the comparison. 
    
    
     
       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 trading environment in which an embodiment of the present invention operates; 
         FIG. 2  depicts a timeline chart of a portion of an exemplary trading day; 
         FIG. 3  depicts exemplary trading records generated by a trading interface; 
         FIG. 4  depicts exemplary trading records generated for a single order; 
         FIG. 5  depicts an exemplary set of order records for a specified market participant for a portion of a trading day; 
         FIG. 6  depicts an exemplary set of records for an entire order; 
         FIG. 7  is a flow diagram illustrating a process implemented in an embodiment of the present invention; 
         FIG. 8  illustrates an exemplary data structure of best price data for a specified market participant in a specified financial instrument; 
         FIG. 9  illustrates exemplary data structures used in comparing a market participant&#39;s best price data to market best price data; 
         FIGS. 10A-10B  are a flow diagram illustrating a process implemented in an embodiment of the present invention; 
         FIG. 11  depicts an exemplary consolidated order record; 
         FIG. 12  depicts an exemplary array of consolidated order information; 
         FIG. 13  illustrates an exemplary data structure of consolidated best price data for a specified market maker in a specified financial instrument; 
         FIG. 14  illustrates exemplary data structures used in comparing a market maker&#39;s best price data to market best price data; 
         FIG. 15  depicts an exemplary liquidity report; 
         FIG. 16  depicts an exemplary report on liquidity generated across market centers; and 
         FIG. 17  depicts an exemplary report on liquidity generated by individual market participants. 
     
    
    
     DETAILED DESCRIPTION 
     Referring to  FIG. 1 , a trading environment in which an embodiment of the liquidity analysis system and method of the present invention is depicted. The examples discussed herein describe the use and application of the present invention in an equity security 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., securities, futures contracts, options, bonds, etc.). In the environment depicted, multiple market participants interact with a trading interface  24  of a market center  22 , for example market makers  40  and broker/dealers  42  in this embodiment. Four market makers  40   a - d  and two broker/dealers  42   a - b  are depicted in  FIG. 1  for the sake of discussion, but it should be understood that any number of market makers  40 , broker/dealers  42  or any other market participant could interact with the market center  22 . The trading interface  24  of the market center  22 , in this example, is a program that allows market participants to enter information regarding their trading interests, such as orders and quotes, validates and then processes the information (e.g., executing orders, publishing quotations, etc.). However, it should be noted that such tasks may be handled by other components of a market center&#39;s trading-related systems without impacting the nature of the invention discussed herein. The market center  22  also maintains data in exemplary data structures  26 ,  28 ,  30 . This data may include, among other information, data regarding trading interest, such as order data, which is stored in trade information data structures  28 . The market center  22  of the present invention includes a liquidity engine  32  that analyzes and reports on market center liquidity, which is discussed in detail below. It should be noted, however, that the present invention can be used to analyze and report on any market participant&#39;s or any market center&#39;s trading interest that includes a price and a size. Terms such as “quote” and “order” are used for clarity and are merely exemplary of the types of “trading interests” that can be processed. Furthermore, the examples and accompanying figures focus on order processing so that the present invention may be most easily understood, and these depictions are not intended to limit the scope of the present invention. The liquidity engine  32  can analyze any trading interest generated by any individual or any number of market participants or market centers. 
     Throughout the discussion herein, it should also be understood that the details regarding the operating environment, data structures, and other technological elements surrounding the liquidity engine  32  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, it should be understood that the market center  22  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. The market center of the type described herein may support any type of trading interface on any suitable computer system, and in this embodiment, the code for the trading interface  24  and the liquidity engine  32  are stored in the market center&#39;s memory. 
     In this embodiment, the market center  22  receives data feeds  34  that contain information from many other market centers, including quote and trade information. This market center information for the entire market is analyzed to determine the market best bid and offer (“BBO”) in the market for any security at any given time. The BBO information is stored in the market center  22  in data structures  26 . The BBO, which is also referred to as the “inside market,” is the highest bid and the lowest offer available in the market at a specific time. If a higher bid or lower offer is made, the BBO is updated immediately, and the new price becomes the “inside market.” The gap in price between the highest bid and lowest offer for a market maker is called the “spread” or the “market maker spread,” since the market makers typically are responsible for generating markets by making quotes in their assigned securities. The term “spread” is also frequently used to describe the gap in price between the highest bid and the lowest offer for a market center and other market participants. The smaller the spread (i.e., the closer the gap between the bid and the offer), the better it is for market liquidity and, as a result, the better it is for issuers and investors. In this embodiment, the liquidity engine  32  compares each market maker&#39;s personal best bid and offer to a market BBO and stores the resulting liquidity information in data structures  30 . This comparison results in liquidity information measuring how often each market maker  40  or market participant is at or near the market BBO in each security traded throughout the day. The examples discussed herein describe the use and application of the present invention with equity security products, but it should be understood that the present invention could be used with any type of security or financial instrument (e.g., futures contracts, options, bonds, etc.). 
       FIG. 2  illustrates how a market is made in a security in a simplified trading scenario and how a market maker&#39;s trading interests relate to the market BBO. Such information is used by the liquidity engine  32  of the present invention to determine a market maker&#39;s ability to generate liquidity. When a market maker  40  initially enters a bid to buy or an offer to sell a security, that trading interest remains “alive” in the trading interface  24  until all of the shares designated in that trading interest are accounted for, such as by being executed, cancelled, transferred, etc. A market maker  40  may enter multiple orders and quotes into the system for the same security at the same or at different prices. However, for the purpose of determining a market maker&#39;s ability to generate liquidity, only the highest bid or the lowest offer price for that security is considered. It should be understood that the example of trading practices depicted in  FIG. 2  has been simplified for the sake of explanation. 
     In the example depicted in  FIG. 2 , at 9:00 a.m., the given market maker  40  enters Order  1  to buy 100 shares of fictitious security WWW for $20, as indicated at  58   a . Since the market maker  40  does not have any other trading interest for security WWW active at this time, his best personal offer is $20. The line  62  on the chart of  FIG. 2  represents the market BBO for security WWW at any given time. At 09:30 a.m., the market maker  40  enters two new orders  58   b ,  58   c , and his best price is now $22. At 10:00 a.m., the market BBO drops to a bid of $22.03, as indicated at  48 , and now the market maker  40  is considered to be “near” the market BBO (since “near” is defined in this example as being within 3 cents of the market BBO). At 10:10 a.m., when the market BBO price drops again, as indicted at  50 , the market maker  40  is now matching the market BBO. Within the next 5 minutes, the market maker  40  executes some of the shares in Order  2  ( 58   b ) before the market BBO  62  price moves up to $22.03, as indicated at  56 . The market maker  40  still has remaining shares bid at $22, so the market maker&#39;s best bid remains within 3 cents of the market BBO. At 10:45 a.m., the market BBO  62  drops to $22, as indicated at  60 , and the market maker  40  is again matching the market BBO. The remaining shares of Order  2  ( 58   b ) are executed over the course of the next 5 minutes. When all of the shares in Order  2  ( 58   b ) are exhausted, the market maker  40  no longer has any orders at $22, and his best bid price in this security is once again $20 for 700 shares (the volume of Order  1  ( 58   a ) plus the volume of Order  3  ( 58   c )). This price does not match nor is it near the market BBO. 
     Referring to  FIG. 3 , during the course of the trading day, the trading interface  24  captures all market center trading activity and stores the trade information in data structures  28 . In this embodiment, each market maker  40  is assigned a unique market maker identification code  84 , and the trading interface  24  embeds this code  84  into every order record  90  generated by the trading interface  24 , storing the data in the trade information data structures  28  so that one market maker&#39;s trading Merest records can be distinguished from another&#39;s. In the example depicted in  FIG. 3 , Market Maker ABC&#39;s identification code is ABC  84   a , Market Maker XYZ&#39;s identification code is XYZ  84   b  and Market Maker NNN&#39;s identification code is NNN  84   c . Each order record  90  also contains the time of the transaction  80 , an order identification code  82  which is generated for each order that a market maker  40  creates, the symbol identifying the security  86 , and an order transaction description  88 . In the example depicted, Market Maker ABC&#39;s order has been assigned order identification number  10011  ( 82   a ), Market Maker XYZ&#39;s has been assigned order identification number  10092  ( 82   b ), and Market Maker NNN&#39;s has been assigned order identification number  10148  ( 82   c ). It should be understood that order records can take many varying forms and be of varying sizes and that order records far more complex than the examples described herein may be utilized, and such embodiments are within the scope of the invention disclosed herein. 
     Referring to  FIG. 4 , the trading interface  24  may generate several records  90  for a single market maker order (i.e., records  90   a  and  90   d - g  for Order # 10011  in this example). All records  90  of a single market maker order (e.g., execution records or modification records, such as cancel-replace, cancel, partial fill) will have the same order identification number  82 . In the example depicted in  FIGS. 3 and 4 , the market maker ABC  40   a  initially entered an order to sell 2000 shares of IBM at $90 at 09:17:04 as indicated at record  90   a  ( FIG. 3 ). As noted above, the trading interface  24  assigned the order identification number  10011  to this order. Then, as illustrated in  FIG. 4 , at 10:01:01, the market maker ABC  40   a  cancelled the initial sell order to sell 2000 shares of IBM at $90 ( 90   a ) and replaced it with an order to sell 1000 shares of IBM at $90 ( 90   d ). In this instance, since the orders are related, the trading interface  24  continues to assign the same order identification number  82  (i.e., order #  10011  in this example) to all the records  90  for this order. Records  90   e - g  are also part of order # 10011 . 
     Referring to  FIG. 5 , an example showing the trading history  83  for IBM for a few seconds in Market Maker ABC&#39;s day is depicted, as stored in the trade information data structures  28 . Note that all individual records  90  with the same order identification number  82  constitute an entire order  92 . As an example,  FIG. 6  illustrates all of the records  90   a ,  90   d - g  relating to order # 10011  ( 92   a ). Taken together, these records show the entire length of time that the order  92   a  was open. The order&#39;s start time  94   a  is the time that the order was initially entered  80   a , and the order&#39;s end time  94   b  is the time the last outstanding shares were accounted for. Each event in the life of the order  92   a  is a separate but related record  90 . The original order to sell 2000 shares, as indicated at record  90   a , was replaced by an order to sell only 1000 shares, as indicated at record  90   d . Therefore, in the subsequent three records  90   e ,  90   f ,  90   g , when a total of 1000 shares were sold, all of the shares in the order  92   a  were accounted for and order # 10011  stopped being an active order at 10:01:07 ( 80   g ). 
     Referring to  FIG. 7 , an embodiment of the process of the liquidity engine  32  for use in analyzing market maker activity is illustrated. At step  100 , the engine  32  is initialized. At step  102 , in this embodiment, the engine  32  creates data structures  30  for use in storing the market maker&#39;s best bid, offer, and volume for each second of trading in a given security. At step  104 , similar structures are created for the results of the matching between the market maker&#39;s best bid or offer and the market BBO. It should be noted that the actual storage of the data need not be identical to the structures described herein, only that there is sufficient storage for such data in some appropriate format and configuration. At step  106 , the system begins monitoring trading for the given market maker  40  in the given security  86 , and at step  108  it begins monitoring the market BBO for the security  86 . At step  110   b ,  110   s , the market maker&#39;s highest bid and lowest ask is recorded for every second of the trading day, as are the associated volumes for the given prices. However, the liquidity engine  32  ignores all records  90  for those order types that do not reflect a market maker&#39;s ability to generate liquidity so that such records  90  will not be included in the liquidity analysis that follows. Specifically, orders that were transferred to another marketplace, orders entered as market orders, immediate-or-cancel orders (“IOC”) (i.e., orders to make the trade immediately or cancel the entire order), and NOW orders (i.e., orders to make the trade immediately or transfer the order to another market maker that can fill the order immediately) are examples of those excluded from this liquidity analysis. These types of orders have no impact on market liquidity and if included in the liquidity analysis would skew the final results. For example, market orders, which instruct the market maker to buy or sell at whatever price is presently available in the market, are not proper for inclusion in the liquidity analysis. By definition, executed market orders are always “at the market”, and if these orders were included in analyzing how often a given market maker set his bid or ask price “at the market”, it would improperly skew the numbers to the market maker&#39;s advantage. 
     At step  112   b ,  112   s , the market maker&#39;s best prices are compared to the market BBO for the security of interest for each second, and at step  114   b ,  114   s , the liquidity engine  32  records the results, whether the market maker  40  was at or near the market BBO price. “Near” may be defined as any price range, and it may also be modified to calculate more than one level of nearness to the market-wide prices (e.g., within 3 cents, within 5 cents, etc.). At step  116 , the liquidity engine  32  examines the results of the matching process and calculates liquidity statistics. As discussed earlier, the examples herein calculate the percentage of time the market maker  40  is at or near the market BBO, but the liquidity engine may be configured to produce other statistical analysis (e.g., total time matching the market BBO). At step  118  the liquidity engine  32  outputs the results of the analysis. In the examples herein, the liquidity engine  32  outputs the data to an informational table, but the engine  32  may be configured to produce any appropriate type or format of output. It should also be noted that the steps on the buy side  110   b - 114   b  are identical in processing to the sell side steps  110   s - 114   s , and while the buy side and sell side processing is broken out in this depiction for clarity, the actual buy-sell processing may integrated without changing the nature of the liquidity engine. 
     Referring to  FIGS. 8 and 9 , an example of the process executed by this embodiment of the liquidity engine  32  is illustrated. At 10:01:02 a.m., as indicated at  132 , the liquidity engine  32  determines the market maker&#39;s best (lowest) ask price for IBM is $89 after the market maker  40  enters order # 10019  ( 92   b ) (see also  FIG. 5 ). As indicated at step  110   s  of  FIG. 7  and depicted in  FIG. 8 , the liquidity engine  32  records the price and volume for order # 10019  for that second in the sample data structure  136  at row  140   b  and in the data cells  142   b ,  143   b  corresponding to the second being analyzed. In this embodiment, the data structure  136  is a portion of data structure  30 . Referring to  FIG. 9 , as indicated at step  112   s  of  FIG. 7 , the liquidity engine  32  compares the market BBO for this second to the market maker&#39;s best ask price. In this example, the liquidity engine  32  retrieves the market best ask price at 10:01:02 a.m. ( 144   b ), which in this example is $89 ( 146   b ). The liquidity engine  32  compares this market best ask price ($89) to the market maker&#39;s best ask price ($89) at 10:01:02 a.m. They are the same, so there is a match. The liquidity engine  32  records this in the data structure  136  in the “Match BBO” cell  150   b . The liquidity engine  32  uses this data to compile the statistics it requires to analyze the liquidity generated by the given market maker  40  in a given product. 
       FIG. 7 , and the example discussed above, describe an embodiment of the present invention. It should be understood that numerous variants of the method and system of this invention could be implemented without departing from the spirit or scope of this invention. For instance, the market BBO monitoring at step  108 , the comparison of the market BBO with the market maker&#39;s best price at steps  112   b ,  112   s  or the recording of the results at steps  114   b ,  114   s  could all be performed on a delayed basis, rather than in real-time. Many of the aspects discussed herein with respect to liquidity processing could be delayed by seconds or hours, due to processing capabilities or otherwise, without impacting the liquidity analysis and reporting discussed herein. 
     Referring to  FIGS. 10A and 10B , another embodiment of the process of the liquidity engine  32  of the present invention is illustrated. In this embodiment, all processing of a market maker&#39;s best bid, ask, and volume is executed after the close of trading, rather than second-by-second in real-time. As such, the liquidity engine  32  in this embodiment must recreate the market maker&#39;s trading day in the given product before being able to compile and calculate liquidity statistics. Because the task of recreating a trading day is a complex one, the liquidity engine  32  processing in this embodiment is more complex than the processing illustrated in the “real-time” embodiment of  FIG. 7 . However, once the trading day is recreated, the liquidity engine  32  processing for this embodiment is comparable to the processing conducted in the “real-time” embodiment depicted in  FIG. 7 . This embodiment is most useful in environments where trade data cannot be monitored and processed in real-time by the liquidity engine  32 . 
     As  FIGS. 10A and 10B  illustrate, at step  200 , the engine  32  is initialized, and at step  202 , the engine  32  retrieves all of the trading data records  90  from the trade information data structures  28  for a given market maker identification code  84  in a given security  86 . At step  204 , the liquidity engine  32  separates the buy records  90  from the sell records  90  for the given market maker  40  and security  86 . Then at steps  206  through  210 , the liquidity engine  32  sorts and validates the separated records before further processing. Note that the steps on the buy side  206   b - 210   b  are identical in processing to the sell side steps  206   s - 210   s . In this embodiment, the buy and sell records are separated simply for processing efficiency, but they may instead be processed simultaneously without altering the liquidity analysis. At steps  206   b ,  206   s , the liquidity engine  32  searches all of the records  90  retrieved and groups records  90  with the same order number  82  together into sets, so that an entire order  92  can be analyzed as a single item. At steps  208   b ,  208   s , the liquidity engine  32  removes all records  90  for order types that do not reflect a market maker&#39;s ability to generate liquidity so that such records  90  will not be included in the liquidity analysis that follows. As with the real-time processing embodiment depicted in  FIG. 7 , orders that were transferred to another marketplace, orders entered as market orders, immediate-or-cancel orders (“IOC”) (i.e., orders to make the trade immediately or cancel the entire order), and NOW orders (i.e., orders to make the trade immediately or transfer the order to another market maker that can fill the order immediately) are examples of those excluded from this liquidity analysis. These types of orders have no impact on market liquidity and if included in the liquidity analysis would skew the final results. 
     In steps  209   b ,  209   s , and with reference to  FIG. 11 , the liquidity engine  32  flags the order start time  94   a  and the order end time  94   b  for an entire set of records  90  for a single order  92 . The order start time  94   a  corresponds to the time the order was initially entered, as indicated at  80   a , and the order  92  ends when the last shares in the order  92  are accounted for, as indicated at  80   g  in this example (e.g., when all remaining shares are executed, cancelled, etc.). The start time and end time  94   a ,  94   b  frames the entire order  92 . When the liquidity engine  32  later retrieves each set of records  90  for an order  92 , it must record the order details as it reproduces the market maker&#39;s trading day for this security  86 . As  FIG. 11  illustrates, a post processed order  92  having multiple records  90  is treated as a single event. The liquidity engine  32  in this embodiment treats the multiple records as a consolidated order  240 , which lasts for the duration the order  92  was open at the price and volume for that order. In this example, the multiple records  90  from order # 10011  ( 90   a, d - g ) can be summarized as a $90 order that was active from 09:17:04 a.m. until 10:01:01 for 2000 shares of IBM  90   a . Then, when the cancel-replace is entered, the modified order for 1000 shares of IBM at $90 is active from 10:01:01 until 10:01:07 a.m. as indicated at records  90   d - g . Note that whether the liquidity engine treats this cancel-replace as two distinct orders which share the same order number, or whether it treats the order as a single order with a change in volume, there is no impact on the liquidity analysis. Because the order cancellation ends at exactly the moment the order replacement request takes effect, as indicated at records  90   a ,  90   d  and because the price remains unchanged, the resultant liquidity analysis remains unchanged. Had the cancel-replace indicated at record  90   d  altered the price of the order represented in the original order record  90   a , the liquidity engine  32  would simply treat order  10011  (records  90   a, d - g ) as if it were two separate orders so that the price difference could be accounted for in the liquidity analysis. It should be understood, however, that this level of detail in order analysis is unnecessary in real-time processing ( FIG. 7 ), since the liquidity engine  32  in real-time processing simply identifies the best bid, offer and associated volumes every second. The order number, its analysis and resolution is typically only important in post-processing because the liquidity engine  32  must recreate each market maker&#39;s trading day for a given product. 
     Orders  10019  ( 82   b ) and  10022  ( 82   c ), in  FIG. 11 , demonstrate how standard orders  92  having multiple records  90  (see  FIG. 5 ) are treated as consolidated records  240   b ,  240   c  for processing purposes. Because the processing involved in sorting, validating, and analyzing individual records  90  can be very time- and resource-intensive, steps  210   b ,  210   s  illustrate additional processing efficiencies that may be implemented. For example, if two or more orders  92  are identical in price, start time, and resolution time, their volumes can be added and the multiple orders treated as a single order without skewing the liquidity data. Since these consolidations do not impact liquidity calculations, these types of efficiencies may be added or omitted from the liquidity engine  32  processing without changing the scope of the present invention. 
     At steps  212   b ,  212   s , and with reference to  FIG. 12 , the liquidity engine  32  creates data structures to contain the sorted, validated and consolidated order  92  data for each market maker  40  in a particular security  86  into arrays  248 . These arrays  248  ultimately serve as a second-by-second recreation of the market maker&#39;s trading day. With reference to  FIG. 12 , the liquidity engine  32  creates arrays  248  with rows that represent seconds of the trading day  242  and columns that represent each validated order  244  for the given security  86 . Where a row  242  and column  244  intersect, a cell  246  is formed. At steps  214   b - 220   b ,  214   s - 220   s , the array  248  is populated by the liquidity engine  32 . At step  214   b ,  214   s , the liquidity engine  32  reads the first record, and, in step  216   b ,  216   s , uses the start time and end time  94   a ,  94   b  to identify the starting point and duration for entering the order  92  into the array  248 . The engine  32  locates the row  242  that corresponds to the “start time” for the record and enters the price bid or offered for that order  92  into the appropriate cell  246 . This price is entered into every subsequent row  242  in this order&#39;s column  244  from the “start time” until the “end time.” In other words, the order  92  is represented by a column of prices that begin at the row representing the time the order  92  was initially entered into the system (i.e., the start flag  94   a ) and that end at the row when the order was ultimately resolved (i.e., the end flag  94   b ), which may have been when the order was completely filled, the remaining balance of the order was cancelled, etc. 
     At steps  218   b ,  218   s , the liquidity engine  32  checks to see if the price entered into the newly populated cell  246  matches the price in a cell  246  in another column  244  (i.e., checking whether two or more orders  92  were offered for the same price at the same time). If so, the liquidity engine  32  adds the volumes associated with the orders  92  that occurred at that price and time together and stores this aggregate bid or ask volume. If there is no other order  92  offered at the same price and time, then the liquidity engine  32  stores that order&#39;s volume. At steps  220   b ,  220   s , the liquidity engine  32  determines whether there are additional orders to analyze and, if so, moves on to the next order  92 . This process continues  214   b - 220   b ,  214   s - 220   s  until all of the validated orders  92  for the given market maker  40  are entered into the array  248  for the given security  86 . 
     At step  222   b ,  222   s , and with reference to  FIG. 13 , when there is no further order data to fill the array  248  and the array  248  is finished, the liquidity engine  32  determines, for each second of the day  242 , the market maker&#39;s highest bid or lowest ask price  142  for a particular security  86  and uses the aggregated total volume as the total shares that were bid or offered at that price  143 . At step  224 , the engine  32  consolidates the bid (buy) and the ask (sell) structures into a single data structure containing each market maker&#39;s best bid and ask price for each second of the day in the given security  86 . 
     At step  226  and referring to  FIG. 14 , the liquidity engine  32  takes each best bid or ask price  142  for a market maker  40  determined at steps  222   b ,  222   s , and for each bid or ask price retrieves the corresponding market BBO  146  from the BBO data structure  26  for the same one second time period  140 ,  144 . The liquidity engine  32  then compares the market maker&#39;s best bid or ask price  142  to the market BBO  146  and records whether the market maker matched, as indicated at  150 , or was near, as indicated at  152 , the market BBO. In this embodiment, “near” to the market BBO is defined as being within 3 cents of the market BBO price, but any degree or number of comparisons may be implemented. At step  228 , the liquidity engine  32  then uses the results of the BBO comparisons, as indicated at  150 ,  152 , to calculate the liquidity generated by the market maker  40  for the specified security  86  during the given trading day, and in step  230  the engine  32  uses this data to generate output. 
     Referring to  FIG. 15 , an exemplary market maker liquidity report  260  generated by the liquidity engine  32  of the present invention is illustrated. Such a report  260  is useful in determining how effective any given market maker  40  is in making markets and executing orders. In assessing a market maker  40 , it is important to know how often the given market maker  40  is “at the inside market.” In other words, the measure of the market maker&#39;s ability to generate liquidity is how often the market maker  40  has matched or is very close to the BBO at any given moment throughout the trading day. The report  260  generated by the liquidity engine  32  is a useful tool to measure how long each market maker  40  is at or near the inside market for each security  86 . The report  260 , in this example, shows, for a given market maker  40  in a given security (e.g., IBM in this example as indicated at  261 ), the percentage of time either a bid or ask was at the market BBO  262 , the percentage of time the bid was at the market BBO  264 , the percentage of time the ask was at the market BBO  266 , the percentage of time either the bid or ask price was within 3 cents of the market BBO  268 , the percentage of time the bid price was within 3 cents of the market BBO  270 , the percentage of time the ask price was within 3 cents of the market BBO  272 , the aggregate bid size for all bids that were at the market BBO  274  and the aggregate ask size for all asks that were at the market BBO  276 . The report  260  can present these statistics for a number of market makers  40  which can be broken out by firm or client type (e.g., agency, proprietary, full service market maker) so the liquidity generated by different market makers  40  can be easily compared to one another. In the example report  260  depicted, generic names are assigned to the firm categories, such as “Full Service  1 ” and “Full Service  2 ”, so that a market maker&#39;s privacy may be maintained. However, if a given market maker  40  wants to advertise their liquidity statistics and have them attributed to their name, it would be possible to show the market maker&#39;s name in the report  260 . 
     In other embodiments of the present invention, the liquidity engine  32  may be used to analyze and report on liquidity across market centers or to analyze and report on liquidity generated within a market center by each market participant, because many times market makers may not be the only market participant responsible for generating liquidity in a market center. Sometimes other market participants, such as individual traders, may be responsible for putting a market center at the market best bid or offer price, and market centers, often times, want to know this information. 
     An example of when market centers want to know liquidity across market centers or want to know which specific market participants are generating liquidity is regarding market data fees (e.g., fees for last sale and quotation data). Market data vendors pay market data fees to get raw real-time market data. Market data vendors take this raw real-time market data and reformat it for publishing or reselling. In many instances, market centers use a central market data facility or organization to collect their market data and distribute it to the market data vendors in a consolidated form. The market data vendors then pay the central market data organization directly for the information and do not deal with the market centers. The fees received by the central market data organization must be proportionately re-distributed back to the market centers. Revenues from market data fees are typically allocated back to the market centers based on the total volume of open interest in a security and the total volume of executed trades generated by market participants at a given market center. Other factors may be incorporated into these volume-based revenue allocation calculations, such as time-weighted and share-weighted adjustments and adjustments for liquidity. Where market center liquidity is used as an adjustment parameter, a market center may receive more market data revenue if their market participants provide the best bid or offer (the “inside market”) more often than those at other market centers. Using this type of market data revenue incentive, every market center is encouraged to offer the best possible markets. The liquidity engine  32  of the present invention, by analyzing and reporting on liquidity generated across market centers, may be used in determining the proper revenue adjustment to be paid to each market center due to liquidity.  FIG. 16  is an exemplary report that may be generated for this purpose. 
     In turn, since every market center relies on its market participants to set the markets, market centers may elect to pass some of the market data revenues fees on to the market participants themselves as a financial incentive to continue to create liquid markets. The liquidity engine  32  of the present invention, by analyzing and reporting on liquidity generated by individual market participants, may be used by market centers to implement a financial incentive plan for market participants.  FIG. 17  is an exemplary report that may be generated for this purpose. 
     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.