WO2014019056A1

WO2014019056A1 - Method and system for assembling and processing large sets of financial data

Info

Publication number: WO2014019056A1
Application number: PCT/CA2012/000766
Authority: WO
Inventors: John George Bruce Mclean
Original assignee: FTSE TMX Global Debt Capital Markets Inc
Current assignee: FTSE TMX Global Debt Capital Markets Inc
Priority date: 2012-07-31
Filing date: 2012-08-17
Publication date: 2014-02-06
Anticipated expiration: 2015-01-31

Description

Method and System For Assembling And Processing Large Sets Of Financial Data

CROSS-REFERENCE TO RELATED APPLICATION

(oooi ] This application claims priority to of U.S. Patent Application No. 61/677,880 filed July 31 , 2012, the contents of which are incorporated herein by reference.

FIELD OF THE INVENTION

[00021 The present invention relates to a system and method for processing data, such as financial data or the like. More specifically, the present invention relates to a system and method for assembling and processing large sets of data to produce at least one desired metric.

BACKGROUND OF THE INVENTION

|0003i Financial trading markets operate on data. Pricing data, volume data, credit risk or other rating data, historical trading data, news events, etc. are all important to market participants.

|0004i In particular some data, such as various metrics, are key to the operation of financial markets. Many exchange-based indices, such as the NYSE indices, NASDAQ indices, Dow Jones Indices, the S&P 500, and other metrics are therefore carefully regulated and controlled. However, other significant metrics are not exchange-based and/or are not well regulated.

[ooos] An example of a critical financial metric which was not well regulated is the London Interbank Offering Rate (LIBOR) and the scandal which came to light in 2012 shows how such a metric may be "gamed" by large market participants.

[0006] Further, many metrics represent indices of synthetic or ideal portfolios of instruments and it may be difficult to actually trade such indices as the required liquidity may not be present in the marketplace from time to time. Further, the reliability of such synthetic indices may not be clear as there is no consideration of the liquidity of the instruments in the index. Thus, a trade with a large price change, but a small total volume, can move an index in a non-intuitive manner. |0007| Ideally, indices would exist which are difficult to game (or misrepresent) and which represent actual liquidity for the instrument(s) in the marketplace and such indices would be created by liquidity-based consideration of actual trade data.

[00081 However, problems exist in creating such an index. For example, tracking actual trading data can involve considering and processing very large data sets which can require expensive computing resources. Also problematic is the fact that, for some types of financial instruments, the data required to implement such an index is not available in a reliable form. For example, if such data is obtained for traded bonds from various trading entities, the data will include: irregularities, such as "dirty prices" which represent the price of the bond and accumulated earnings of the bond rather than just the bond price; outliers, such as low volume trades executed at possibly non-indicative pricing; and anomalies, such as repurchases ("Repos"), etc. Thus, the data obtained would result in misleading or erroneous indices.

|0009| Accordingly, it is desired to have a system and method which provides for the processing, creation and maintenance of a liquidity based index derived from actual trading data.

SUMMARY OF THE INVENTION

looioi It is an object of the present invention to provide a novel system and method for assembling and processing large sets of data to produce at least one desired metric which obviates or mitigates at least one disadvantage of the prior art.

loon) According to a first aspect of the present invention, there is provided a system for assembling and processing large sets of financial data, comprising: a data computational engine operable to receive data records representing trades of financial instruments and to perform data operations upon the data records; a normalization data base operable to maintain data records for each of a plurality of financial instruments, the data records including at least static identifier data and historical trading data for the respective financial instrument, the normalization data base cooperating with the data computational engine to form a data normalization engine operable to autonomously normalize the received data records to identify, according to pre-selected criteria, data records to be removed from further consideration by the system and data records for further processing by the system; an analysis engine, operable on the data records which have been identified for further processing to produce at least one metric reflecting the trading activity of the financial instruments represented by the data, and creating and transmitting at least one data record representing the produced at least one metric to a trading entity.

10012] Preferably, the at least one result from the analysis engine is also provided to the normalization data base, the normalization data base adjusting the pre-selected criteria responsive to the at least one result.

[00131 According to another aspect of the present invention, there is provided a method of assembling and processing large sets of financial data, comprising the steps of: (i) receiving a plurality of data records, each data record representing at least one trade of a financial instrument; (ii) examining each received data record to determine if the value of the at least one trade exceeds a pre-selected minimum trade size criteria and identifying each such determined record for further processing; (iii) examining each identified data record to determine, according to pre-defined exception criteria and data corresponding to the financial instrument from a normalization data base, if the at least one trade of the financial instrument is an exception trade and excluding each data record representing an exception trade from further processing; (iv) providing each data record identified for further processing to an analysis engine, the analysis engine producing at least one metric relating to the received plurality of data records; and (v) providing the at least one metric to a trading entity.

100141 Preferably, the at least one metric is also provided to the normalization data base and is utilized to alter the pre-defined exception criteria and/or the at least one metric is also provided to the normalization data base and is utilized to alter the pre-selected minimum trade size criteria.

|00i5| The present invention teaches a method and system for assembling and processing large sets of data to produce at least one desired metric. In particular, the present invention teaches a method and system for receiving large data sets, such as of trading records for financial instruments, which can include irregular, anomalous and outlier data records. The system and method operate to normalize the received data to identify irregular, anomalous and outlier data records of trades and to remove such identified data records from further processing by an analysis system which can produce one or more desired metrics. By removing the identified records from subsequent analysis, higher quality metrics can be obtained and required computational resources can be reduced. The resulting high quality metric can also be fed back into the normalization process to improve the efficacy of the normalization process on an iterative basis.

(00161 Further, the present invention allows the creation and maintenance of novel financial metrics which reflect both price and liquidity for a financial instrument.

[0017] Other features and advantages of the present invention are described more fully below.

BRIEF DESCRIPTION OF THE DRAWINGS

[00181 Preferred embodiments of the present invention will now be described, by way of example only, with reference to the attached Figures, wherein:

Figure 1 shows a block diagram of a system for assembling and processing large sets of financial data, in accordance with an embodiment of the present invention; and

Figure 2 shows a flow chart representing a method of normalizing financial data in accordance with the present invention.

DETAILED DESCRIPTION OF THE INVENTION

|ooi9| A system for assembling and processing large sets of financial data, in accordance with an embodiment of the present invention, is indicated generally at 20 in Figure 1. In the illustrated embodiment, a plurality of trading entities, collectively identified as 24 and individually identified as 24a through 24,, participate in trades in the financial instruments of interest. Trading entities 24 can buy or sell instruments of interest either for their own interest or for the accounts of their clients and it is also contemplated that a trading entity 24 may process trades for other trading entities.

I0020] In the present invention, each trading entity 24 will report 30 each trade they have completed or handled either to a central clearing house 36, or individually and directly (not illustrated in the Figure) to a processing system 42 as described below.

J00211 Central clearing house 36 can be a financial exchange or can be a clearing and/or depository service such as, for example, CDS Clearing and Depository Services Inc., 85 Richmond Street West, Toronto, ON, Canada or any other entity to which trades in the financial instrument, or instruments, of interest are reported. 100221 As mentioned above, it is also contemplated that, for financial instruments wherein there is no appropriate central clearing house 36, each trading entity can report 30 each trade directly to processing system 42. In such a case, it is preferred that such reporting be required, under appropriate regulatory regimes, although it is also contemplated that such direct reporting could be voluntary.

|0023| As mentioned briefly above, the trading data reported by trading entities 24 (by which ever means) to processing system 42 may not be in a reliable form, even if when such reporting is required by a relevant regulatory regime. Accordingly, processing system 42 includes a data normalization engine 46 which processes reported trading data to remove irregularities, anomalies and outlier transactions.

|0024| Data normalization engine 46 comprises a data computational engine 50 and at least one normalization data base 54. Computational engine 50 can be any suitable computational device such as a general purpose computer executing a suitable operating system, such as BSD Unix or Red Hat Enterprise Linux and appropriate software, as described below. Normalization data base 54 can be any suitable data base system operable to maintain the necessary data, as described below, and can be for example an Oracle, DB2 or MySQL data base system executing on appropriate hardware and storage devices.

[00251 Due to the wide variety of financial instruments that may be traded, normalizing reported trading data can be a difficult task. For example, when considering financial instruments such as bonds, a variety of factors must be considered including: whether the reported trade price is "dirty" (i.e. - reflects the bond price and coupon payments and/or other earnings, rather than just the bond price); whether the reported trade is a repurchase, and therefore not a trade of interest in producing an appropriate index/metric; whether the trade is an outlier due to small volume and irregular pricing; etc.

[00261 Accordingly, normalization data base 54 is purpose constructed to include all relevant data, regarding financial instruments of interest, which can assist in the normalization process. For example, for bonds normalization data base 54 will include an agreed (preferably standard) identifier of the bond, issuer identification data, term of the instrument, payment (coupon, etc.) terms and timing, historical trade data for the instrument, etc. Stripped coupon bonds, or other variants of instruments, can have distinct identifiers or sub- fields within the identifier can identify such variants. 10027] As should be apparent to those of skill in the art, normalization data base 54 not only maintains static data, but also dynamically maintains historical records reflecting the normalized trades, as created by processing system 42, which are used in subsequent normalization processing. In this way, normalization data base 54, and the rest of processing system 42, as a closed loop (or feedback) system to better perform normalization of reported trading data.

100281 As trading data is provided, computational engine 50 processes the trading data to determine if it is of interest, or can be made of interest, to processing system 42. The following discussion is provided, by way of example only, as examples of some of the normalization techniques which can be applied by data normalization engine 46. Many of the following examples relate specifically to bonds, but it will be apparent to those of skill in the art that the present invention is not limited to use with bonds and can, in fact, be utilized with a wide range of financial instruments and bonds have been selected for discussion herein as they provide one of the more challenging cases for consideration.

10029] As an example of a first normalization step, for each received trade record in trading data received from trading entities 24, data normalization engine 46 will consult normalization data base 54 to determine if the traded financial instrument, in this example a bond, is a real return issue (which is static data for the issue) and, if it is, to determine if the reported trade price is within a pre-selected tolerance band (e.g. - 5%) of the determined price for the last trading day, as previously determined by processing system 42 and stored in normalization data base 54. If the trade record is a real return issue and the price is within the tolerance band, the trade will be further processed.

100301 Next, for each received trade record in trading data received from trading entities 24, data normalization engine 46 will consult normalization data base 54 to determine if the traded financial instrument is a bond issued by a corporation, and, if it is, to determine if the reported trade price is within a pre-selected tolerance range (e.g. - -5% to +6%) of the determined price for the last trading day, as previously determined by processing system 42 and stored in normalization data base 54. If the trade record is a corporate issue and the price is within the tolerance range, the trade will be further processed.

[00311 Next, for each received trade record in trading data received from trading entities 24, data normalization engine 46 will consult normalization data base 54 to determine if the traded financial instrument is a bond issued by a Government and, if it is, to determine if the reported trade price is within a tolerance range defined by a historical trading range for the instrument, as previously determined by processing system 42 and stored in normalization data base 54. If the trade record is a Government issue and the price is within the tolerance range the trade will be further processed.

(00321 Next, for each received trade record in trading data received from trading entities 24, data normalization engine 46 will consult normalization data base 54 to attempt determine if the price reported for the trade is an irregular (dirty) price by subtracting any accrued earnings for the instrument (as maintained by, and obtained from, normalization data base 54) from the reported trade price. If the resulting determined price appears to be within an acceptable tolerance range for the instrument, the trade will be further processed.

[00331 Next, for each received trade record selected for further processing, data normalization engine 46 will consult normalization data base 54 to attempt determine if the trade represents a repurchase transaction. In some circumstances repurchase transactions can be explicitly reported via an appropriate data field in the trade record, while in other circumstances data normalization engine 46 will make such a determination itself based upon data from normalization data base 54, such as the type of issuer, the price trade price compared to previous trade prices, the volume of the transaction, etc. Trades which are determined or deemed not to be repurchases will be further processed.

[00341 Once the above normalization processes (and any other normalization processes as will occur to those of skill in the art which may be appropriate and/or desired) have been performed for a trade record, data normalization engine 46 will select the reported trade records which have been identified for further processing and which meet any additional criteria, such as a pre-defined liquidity criteria, such as trades which have a value in excess of $500,000, etc.

[0035] As will be apparent to those of skill in the art, different liquidity criteria can be applied to different types of instruments (i.e. Government bonds, versus Corporate Bonds) and/or in view of other criteria, such as remaining term of the instrument, total size of the issue, etc., which data can be maintained in normalization data base 54.

[00361 Selected trade records are further processed by processing system 42, as described in more detail below. |0037| Figure 2 shows a flow chart representing a data normalization process in accordance with an embodiment of the present invention. At step 100, processing system 42 receives trading from trading entities 24 and transfers that data to data normalization engine 46.

|0038| At step 104, data normalization engine 46 analyzes each received trade to determine if the reported trade is an irregular trade, such as a "dirty price" for a bond, and marks each determined irregular trade for no further processing by processing system 42. |0039] Alternatively, and not shown in Figure 2, at step 104 data normalization engine can further attempt to "clean" dirty prices or the like by calculating a clean price from a determined reported dirty price by adjusting the reported dirty price by the amount of any accrued interest or other amounts earned. In such a case, a determined dirty priced trade record for which data normalization engine 46 can create a clean price will be marked for further processing by processing system 42 but with the clean price being employed.

|0040i At step 108, data normalization engine 46 analyzes each received trade to determine if the reported trade is an anomaly and marks each determined anomalous irregular trade for no further processing by processing system 42.

|004i | At step 1 12, data normalization engine 46 analyzes each received trade to determine if the reported trade is an outlier and marks each determined outlier trade for no further processing by processing system 42.

I0042] As used herein, irregular, outlier and anomalous trades are referred to as "exception trades". As will be apparent to those of skill in the art, the present invention is not limited to defining exception trades as those which are which are irregular, outlier or anomalous and, instead, a wide variety of criteria can be employed to identify exception trades. As should also be apparent to those of skill in the art, the criteria used to identify exception trades will vary by type of financial instrument (i.e. - bonds, T-Bill, stock, Warrants, etc.) and can vary even within a type of financial instrument (i.e. - Government Issued Bonds, Corporate Issued Bonds, etc.) and the definition and selection of appropriate criteria is within the normal skill of those skilled in the art of financial trading.

|0043| Next, at step 1 6 data normalization engine 46 analyzes each received trade to determine if the trade meets or exceeds a pre-defined trade size criteria. As mentioned above, such a trade size criteria can be selected for all trades, or different criteria can be selected for different types or categories of financial instruments. For example, system 20 can have a predefined trade size criteria of greater than $499,000 for all trades, or can have a criteria of greater than $750,000 for government issued bonds, and greater than $499,000 for corporate issued bonds, etc.

[0044| It is further contemplated that such trade size criteria can be dynamic, for example representing a percentage of the total reported trade volume on a day. In such a case, a minimum trade size criteria of 0.1 % of reported trading volume on a day with $1 Billion in reported trades would result in trades of less than $1 Million not being further processed, while on a day with only $500 Million in reported trades, trades of less than $500 thousand would not be further processed. It is also contemplated that, in some circumstances and for some financial instruments, the trade size criteria can be a selected trade volume.

|0045| Alternatively, a trade ratio criteria can be employed wherein the ratio of the size of the trade to the total outstanding issued amount of the financial instrument under consideration is compared to a pre-defined minimum ratio and trades which do not meet the pre-defined minimum ratio are deemed to be exceptional.

[0046| The method concludes at step 120, wherein all remaining trades (i.e. - those not marked for no further processing) are appropriately forwarded to analytic systems, described below.

|0047| As will be apparent to those of skill in the art, the process of normalizing the reported trade data allows for the creation and use of indices and metrics which were previously not generally available with a high level of quality in the reported data. Further, by removing irregular, anomalous and outlier trades from further processing, the computational resources which are required to produce the desired indices, metrics and data are reduced from those which would otherwise be required.

[0048I Once data normalization engine 46 has identified all relevant reported trades for further processing, analysis engine 60 can begin processing those remaining trades. Analysis engine 60 can be any suitable computer processing system such as a general purpose computer executing a suitable operating system, such as BSD Unix, Red Hat Enterprise Linux or Microsoft Windows and appropriate software, such as the PC-Bond analytics package presently available (at the time of filing of this application) from TSX Inc., the present assignee of the present invention or any other suitable analytics and/or statistical analysis software.

100491 Analysis engine 60 will process the trade data provided by data normalization engine 46 to produce desired indices and/or metrics for various market entities 64 who are interested in such data, including regulators, issuers, trading entities 24, news agencies and indices publishers etc.

|0050] For example, analysis engine 60 can produce a set of financial instrument prices which prices indicate the prices at which statistically significant trade volumes occurred and this is a significant advantage in understanding real values of the financial instruments. Further, the data produced by analysis engine 60 can be fed back into normalization data base 54 and employed by computational engine 50 to better normalize subsequently received and processed trading data.

100511 In particular, it is contemplated that the normalization of received trading data may be performed on an iterative basis. For example, wherein acceptable trading ranges for various normalization tests can be updated in view of additional received trading data. For example, in a very simple case, data normalization engine 46 may have determined that a bond trade showing a price of $100 was an outlier as historical pricing was $92 and this difference exceeded a defined tolerance range. However if analysis engine 60 determines, from considering a variety of processed reported trading data, that a significant movement has occurred overall in the market (perhaps due to an interest rate movement), appropriate data fed back from analysis engine 60 can be used by data normalization engine 46 to adjust or other compensate its normalization processes. In such a case, data normalization engine 46 will revise its analysis of the $100 bond trade and will mark it for further processing. Thus, while a trade record may be initially be determined to be an irregular or outlier trade, data normalization engine 46 can iteratively reevaluate such trades in light of data fed back from analysis engine 60 and make new determinations as appropriate.

[0052| Further, by providing feedback from analysis engine 60, the definition of tolerance ranges can be updated to reflect actual market conditions. For example, in an active issue and/or active market, a price tolerance range for an issue may be 3% of the average price over a selected time period, while for a less active issue, or in a quiet market, a more appropriate price tolerance range may be 5%. 100531 I is contemplated that this unique, iterative, feedback system will greatly enhance the ability to have data normalization engine 46 autonomously normalize reported trading data.

|0054| Another issue which can arise is that trading entities 24 may not have to (or be able to) report trades to central clearing house 36, or to processing system 42, until the settlement date of the trade. Settlement dates can be, for example, same day, or one, two or three days after a trade occurs depending upon the instrument, where it is traded, etc. Thus, processing system 42 can be receiving trade reports for, in some cases, up to four different trading days. |0055| While it will be apparent that processing system 42 can merely wait until all relevant trades have been reported (i.e. - wait until the settlement day) before beginning processing of reported trades, the present inventor believes that additional advantages are obtained in processing reported trades, when received at processing system 42.

10056) In such a case, it can be decided that processing system 42 will release processed data once a day, or more often, for each day between the trade date and the settlement date. Thus, a market entity 64 can have access to both "settled data" (i.e. - the total received and processed trade data reflecting all processed trades for a settlement date) and "preliminary data" reflecting the processed trade reports to date, prior to the settlement date. As an example, for trades with a three day settlement deadline, a market entity 64 could receive, on May 3rd, settled data for trades made on May 1 (and settled on May 3^rd) and preliminary data for trades made on May 2^nd and not yet settled (or reported) and preliminary data for trades made of May 3^rd and not yet settled (and reported).

[0057] On May 4^th, the market entity 64 would then receive settled data for the trades made on May 2, which may or may not be different than the preliminary data provided for those trades on May 3^rd, and revised preliminary data for trades made on May 3^rd, as well as preliminary data for trades made on May 4^th.

I0058] It is believed that, by providing sets of preliminary data to market entities 64, such entities will be better informed and will be able to participate in markets more effectively. Further, in the case wherein data normalization engine 46 iteratively normalizes reported trades, such preliminary data feedback can more quickly improve the normalization process than would be the case if feedback only occurred at the settlement date. Further, by iteratively normalizing reported trade data, the computational workload can be spread over time, thus reducing or avoiding peak computational requirements and allowing smaller and/or less expensive computational engines to be employed within system 20.

100591 As mentioned above, not all financial markets require trading entities 24 to report all trades. In cases were such reporting is not required, it is contemplated that the results produced by processing system 42 can be distributed only to trading entities who contractually agree to report their trades, or that the results produced by processing system 42 will be provided first to trading entities 24 who report their results and subsequently to other trading entities 24 as a method of encouraging participation by a majority of trading entities 24.

[0060] As should now be apparent, the present invention allows the creation and maintenance of novel financial metrics which reflect both price and liquidity for a financial instrument. For example, with prior art indices for individual financial instruments, price data is typically shown for the last reported trade, irrespective of the volume of that trade. Similarly, many indices are composites of last trade prices for a pre-selected set of financial instruments. For instruments with good liquidity (e.g. - many stocks) this has been a reasonable approach. However, for financial instruments which may exhibit less liquidity and/or which are not traded on a regulated exchange, such metrics have reduced utility.

100611 In contrast, by employing the present invention normalized trading data can be employed for such metrics and indices, creating and providing what the present inventor believes is a more informative set of data for financial traders. Further, metrics and indices produced in accordance with the present invention are less susceptible to "gaming" or other fraud as data normalization engine 46 will identify outlier and/or irregular trades which could otherwise be used to influence such indices and metrics.

|0062| The present invention teaches a system and method for assembling and processing large sets of data to produce at least one desired metric. Preferably, the system and method can process large sets of financial data and operate to normalize that data to remove irregular and anomalous data, as well as outlier data. By normalizing the received large data sets, the computational resources which would otherwise be required to conduct analysis and processing of the data are reduced and the resultant quality of the data set can be improved. In a preferred aspect, the normalization process is improved by feedback of results from the analysis engine of the system to the data normalization engine, allowing normalization tests and thresholds to be adjusted iteratively. While the discussion herein has concentrated primarily on processing financial data, it is contemplated that the present invention can also advantageously be employed in other fields including commodities and resources trading, etc.

[00631 The above-described embodiments of the invention are intended to be examples of the present invention and alterations and modifications may be effected thereto, by those of skill in the art, without departing from the scope of the invention which is defined solely by the claims appended hereto.

Claims

We claim:

1. A system for assembling and processing large sets of financial data, comprising:

a data computational engine operable to receive data records representing trades of financial instruments and to perform data operations upon the data records;

a normalization data base operable to maintain data records for each of a plurality of financial instruments, the data records including at least static identifier data and historical trading data for the respective financial instrument, the normalization data base cooperating with the data computational engine to form a data normalization engine operable to autonomously normalize the received data records to identify, according to pre-selected criteria, data records to be removed from further consideration by the system and data records for further processing by the system;

an analysis engine, operable on the data records which have been identified for further processing to produce at least one metric reflecting the trading activity of the financial instruments represented by the data, and creating and transmitting at least one data record representing the produced at least one metric to a trading entity.

2. The system of claim 1 wherein at least one result from the analysis engine is also provided to the normalization data base, the normalization data base adjusting the preselected criteria responsive to the at least one result.

3. The system of claim 1 wherein the data computational engine receives the data records from a plurality of trading entities.

4. The system of claim 3 wherein the analysis engine transmits the at least one data record to each of the plurality of trading entities.

5. The system of claim 1 wherein the data computational engine receives the data records from at least one central clearing house.

6. The system of claim 1 wherein the pre-selected criteria is configured such that the data normalization engine removes from further processing data records representing financial trades which are not representative of the value of the financial instrument they relate to.

7. The system of claim 6 wherein data records removed from further processing include data records representing at least one of an irregular, anomalous or outlier priced trade.

8. The system of claim 6 wherein data records removed from further processing include data records representing trades whose value is less than a predefined amount.

9. The system of claim 1 wherein the at least one metric includes a data record representing an index derived only from financial instruments which meet a predefined liquidity criteria.

10. The system of claim 2 wherein the data normalization engine iteratively performs the identification of data records to be removed from further consideration by the system in response to the updating of the normalization data base with the at least one result from the analysis engine.

11. A method of assembling and processing large sets of financial data, comprising the steps of:

(i) receiving a plurality of data records, each data record representing at least one trade of a financial instrument;

(ii) examining each received data record to determine if the value of the at least one trade exceeds a pre-selected minimum trade size criteria and identifying each such determined record for further processing;

(iii) examining each identified data record to determine, according to pre-defined exception criteria and data corresponding to the financial instrument from a normalization data base, if the at least one trade of the financial instrument is an exception trade and excluding each data record representing an exception trade from further processing;

(iv) providing each data record identified for further processing to an analysis engine, the analysis engine producing at least one metric relating to the received plurality of data records; and

(v) providing the at least one metric to a trading entity.

12. The method of claim 1 wherein the at least one metric is also provided to the normalization data base and is utilized to alter the pre-defined exception criteria.

13. The method of claim 1 1 wherein the at least one metric is also provided to the normalization data base and is utilized to alter the pre-selected minimum trade size criteria.

1 . The method of claim 1 1 wherein the at least one metric comprises a index comprised of financial instruments whose data records representing trades have exceeded the preselected minimum trade size criteria.

15. The method of claim 1 wherein the pre-selected minimum trade size criteria differs for different financial instruments.

16. The method of claim 11 wherein the pre-defined exception criteria differs for different types of financial instruments.