Security analyst performance tracking and analysis system and method6510419Abstract A system and method for measuring, analyzing, and tracking the past performance of security analysts' earnings estimates and recommendations. A database containing historical information pertaining to analyst earnings estimates and recommendations is downloaded into the system. Pre-calculated data values are also added to the database including adjustment factors a single or set of analysts based upon their historical earnings estimates as compared to actual earnings estimates over time, and other user-defined performance analysis set parameters and metrics. A weighting factor may also be calculated for a set of analysts based upon factors such as the recency of an analyst's earnings estimates. Using these adjustment and weighting factors and each analyst's actual earnings estimate, a custom composite estimate may be derived. A front-end graphical user interface (GUI) is used to view analyst historical data either as raw data or, by using a data visualization technique, as a graph or chart. The GUI allows a user to choose from a multitude of predetermined analysis parameters and metrics or to define his own parameters and metrics for calculation and visualization. A user may also, in similar manner, use a GUI to choose parameters and metrics to analyze and display the historical profitability of analysts' recommendations over a plurality of time periods. Claims What is claimed is: Description FIELD OF THE INVENTION
TABLE 1
Not pre-calculated
Comparable (across
(Calculated
stocks, time
Event 0-3 3-6 6-12 0-12 0-24 on-the-fly)
periods)
Avg-Error $ X X X X X
Avg-Abs Err $ X X X X X
Avg-Abs Err %ile X X X X X
X
Avg-Error % X X X X X X
Avg-Abs Err % X X X X X X
Avg-Rel Error % X X X X X
X
Avg-Bias Error % X X X X X
X
Actual-Divisor (for % X
calcs)
Swings X
X
Hit % X
X
Total Estimates X
X
Follow % X X X X X
X
LeadLagScore X
X
MTBR X
X
Best Date X
Best Error (Rel Err %) X
Year first followed X
The calculations to derive these error metrics are provided in Table 2. Example ranges, analysis of these values and characteristics are provided although other ranges, analysis and characteristics may also be provided.
TABLE 2
Formula Range Analyzing
Characteristic
Error $ ##EQU1## Any Closer to 0
is better Error in dollars and cents
Abs Error $ ##EQU2## 0 to Any Closer to 0
is better. Absolute Value of Error in $ and cents. When average is taken
over interval, negative and positive errors do not cancel out- preserves
magnitude of error but not sign.
Rel Error Pct ##EQU3## Any Larger
negative Numbers are better Error Compared to the Consensus Error
Bias Error If analyst's estimate is further from the Any. Usually Closer
to 0 is Relative Error % only
Percent actual than the consensus estimate is, then a low number
better. if the Analyst is further
Biaserror = Relative Error %
from the actual than
Else
the consensus.
Biaserror = 0
Average Bias Error % For period t1 . . . t2 =
##EQU4##
Additionally, other metrics including leadlag factor, swings, hits, hit percent, and mean time between revisions may be included as metrics. Table 3 below described these metrics, how they are calculated, analysis for these metrics, and a range for these metrics.
TABLE 3
Formula
Analysis Range
Leadlag Factor ##EQU5## Closer
to 1 is better 1 = Always Leads, -1 Always Lags -1.0 to +1.0
Swings (i.e., number of times in period that analyst "stuck neck out" more
than [SwingStdDevs = 1.5] standard deviations away from the consensus as
measured [n = 5] days after estimate date T.) ##EQU6##
Many swings indicate that analyst is willing to express an
opinion independent from the pack. (It does
# not indicate quality.) A low number of swings may indicate an analyst
that follows the pack. Positive Integer, Or 0.
Hits A Hit is a Swing that is closer to the actual
-- Positive
than the consensus.
Integer or 0
If
##EQU7##
Hit Percent ##EQU8## 100%
indicates all Hits 0% indicates all misses NA indicates no Swings 0-100%
MTBR - Mean Time Between Revisions ##EQU9##
Average in our current database is 89.1 days 0-365 days
These metrics are understood as follows: Error $--The difference between Est.sub.1 and the Actual. Expressed in dollars. Abs Err $--The absolute value of Error $ at a point in time. Bias Error Percentage--If Consensus>Actual, then Bias Error equals Relative Error %, else it is 0. If Consensus<Actual, then Bias Error equals Relative Error %, else it is 0. Actual-Divisor (Applies to Err %, ABS(Err %), and RelErr %)--To facilitate cross-stock and cross-period comparison of error, we provide metrics that normalize estimates & error by the size of the actual earnings. Of course, for small actual values, errors become exaggerated. To avoid this, we limit the divisor to be no less than 0.40 cents for fiscal year events and no less than 0.10 for fiscal quarter events. Relative Error Percentage--The difference between the analysts error and the consensus error, divided by the Actual-Divisor. Swings--Often, major revisions (N Std Dev away from consensus) occur simultaneously for multiple analysts. For example, this may be the case when a company reports a large earning surprise or issues a warning about upcoming growth. "Swings," which are bold estimates that differ greatly from the consensus, are differentiated from major revisions that occur concurrently with, or near to, major revisions from other analysts. To achieve this, the system may measure whether an analyst estimate or revision is N standard deviations away from the consensus N (typically 5) days after the day the analyst's estimate was made. Swings may be measured over the 24 months prior to the report date. Unlike other error metrics which are calculated by sampling (continued) estimates over an interval and computing the corresponding average error, Swings may be determined by considering only the actual estimates or revisions. The default number of Std Dev is 1.5. Hit Percent--A hit is a swing that proves to be closer to the actual than the consensus at N days after the date of the swing. Total Estimates--The total number of estimates made by the analyst in the prior 24 months for the event. Confirmations are not included. An estimate pre-existing exactly 24 months prior to the report are counted in the total. Follow Percent--In each time frame (0 to 3, 3 to 6, 6 to 12, 0 to 12, 0 to 24 months) we calculate the total availability of the analysts estimates during that time. Follow Pct equals the days the analyst estimate was available in the timeframe divided by the total number of days in the timeframe. MTBR--Mean Time between Revisions--Measures frequency of analyst revision in the year prior to the report date. Equals the number of days in which there was an active estimate in the year prior to the report date divided by the Total Estimates. Best Date--The day in which the analyst's error (RelErr %) was lowest in the 24 month prior to the report date for that event. Best Error--The value of the analyst's lowest RelErr % at the corresponding Best Date. Further, a lead lag score may be provided. In calculating the lead lag score, Table 4 represents calculations with the following understanding: C.sub.0 represents the consensus on the day of the estimate in question, C.sub.1 represents the consensus on the n-th day prior to the day of the estimate in question, and C.sub.2 represents the consensus on the n-th day following the day of the estimate in question. These conditions are considered in this order to determine if an estimate is leading, lagging, or neither:
TABLE 4
# Condition Formula
Classified as
1 Change in consensus, from n days prior to .vertline.c.sub.2 -
c.sub.1.vertline./MAX(FudgeFctr,.vertline.c.sub.1.vertline. > Min %
Else
n days following estimate, must be at least
Neither
Min %, (default = 5%). Else "neither"
2 Consensus change prior to the estimate (C2 > C1) AND (C2 >= C0)
Else
must not be different in direction from OR
Neither
change after the estimate. (C2 < C1) AND (C2 <= C0)
3 Number of Estimates/Revs Between [t - n to t + n] minus [# estimates at
t] >= 2 ##EQU10## Else Neither
4 If the Number of Estimates prior to the Estimate Date in the time frame
are greater than the number of estimates after the report date in the time
frame. Then this estimate is a lagging estimate. ##EQU11##
Lagging
5 If the Number of Estimates prior to the Estimate Date in the time frame
are less than the number of estimates after the report date in the time
frame. Then this estimate is a Leading estimate ##EQU12##
Leading
6 If the Number of Estimates prior to the Estimate Date in the time frame
are equal to the number of estimates after the report date in the time
frame. Then this estimate is neither a leading nor lagging estimate.
##EQU13## Neither
For each analyst, each new estimate or revision made within 24 months of a report date for a fiscal period is classified either as Leading, Lagging or Neither according to the logic above. The LeadLagFactor is the number of Leading estimates minus the number of Lagging over the total estimates. If all estimates were lagging, the LeadLagFactor=-1.0; if All estimates were leading, the LeadLagFactor=+1.0. If all estimates were "neither" or if the number of Leading Estimates equals the number of Lagging estimates, the LeadLagFactor=0.0. Estimates already current at 24 months prior to the report date may not be included. ##EQU14## Based on the information in this database, various other calculations may be derived. For example, based on the historical information for each analyst, an adjustment factor may be calculated. Generally speaking, the adjustment factor represents the analytical "bias" which may or may not be incorporated into each analyst's earnings estimate, for a particular security, over a given period of time. For example, an analyst who has, over a specified time period, issued earnings estimates for a particular company that were, in hindsight, on average too high, might be assigned an adjustment factor of 0.95 for that performance analysis set, such that the analyst's issued estimate over the specified time period is reduced by five percent. Conversely, an analyst who has historically issued estimates over a specified time period that were, in hindsight, on average too low might be assigned an adjustment factor of 1.10 for that performance analysis set, such that his actual reported estimate for that time period is increased by ten percent. Notably, although the adjustment factor calculated for any given performance analysis set may be stored in the system's database, adjustment factors are typically generated in real time in response to user-defined inputs. As indicated above, the calculation of an adjustment factor will generally be based upon a comparison of the historical earnings estimates issued by an analyst, for a given security followed by that analyst, over a particular time period. A user may also define further analysis parameters and metrics such that, for example, as specified by a user, the determination of an adjustment factor may take into account an analyst's historical percentage error as compared to actual earnings, generally available consensus earnings estimates, custom composite adjusted earnings estimates, or other metric. One example of a user-defined parameter is the assignment by a user of a scaling factor to be applied in the calculation of the adjustment factor for a given performance analysis set. For example, a user may define a performance analysis set such that, for that analysis set, a particular analyst is shown to have issued estimates that were on average 20 percent greater than actual earnings. The user will then be able to assign a scaling factor, say for example, 0.5, to be multiplied by the 20 percent error such that the effective adjustment factor for that user-defined performance analysis set reflects a 10 percent and not a 20 percent adjustment--i.e., an adjustment factor of 0.9, rounded to the nearest tenth. Thus, in this particular example, the user "discounted" the analyst's earnings estimate bias as indicated by the system's calculations. The formula for the calculation of the adjustment factor is set forth below: [1/(1+(Error metric*Scaling factor))] An improved estimate of an analyst's earnings may also be accomplished by the calculation of a weighting factor which is used to provide a weighted average of an analyst's earnings estimate, as compared to other analysts. As with the adjustment factor, this weighting factor may be based upon a variety of user-defined parameters and metrics. For example, a weighting factor for a given analyst, security, and time period may be calculated based upon the relative recency of the issuance of analyst's earnings revision or the historical consistency and/or accuracy of an analyst's adjusted estimates (as compared to actual earnings), or a combination of these or other related factors or metrics. For example, if an estimate of one analyst is relatively old compared to an estimate or revision of a second analyst, the former might be assigned a relatively low weighting factor, (or even zero in some cases), as compared to a more recent estimate produced by the second analyst. This is done based upon the assumption that a more recent estimate is likely to be based upon relatively new and accurate information which may affect a company's earnings potential and, therefore, is more likely to be predictive of a company's actual earnings. Similarly, a weighting factor for a given analyst, security, and time period may be calculated based upon the relative accuracy of one analyst as compared to another. For example, at a specific point in time prior to an earnings event for a specific security, analyst A might have issued an earnings estimate 25 percent greater than the actual earnings ultimately announced, whereas analyst B may have issued an estimate that was 100 percent greater than the actual earnings. Subsequently, at a later point in time, yet still prior to the announcement of actual earnings, analyst A might have revised his estimate so that it was 15 percent greater than the actual earnings, and analyst B may have simultaneously revised his estimate so that it was 80 percent below actual earnings. Although the average errors for both analysts A and B were 20 percent above the actual earnings, the variance over time for analyst A was much less than that for analyst B. Accordingly, analyst A's estimate of future earnings for this specific security might be assigned a weighting factor significantly higher than that assigned to the estimate of analyst B. Regardless of how a weighting factor is calculated, based on the number of analysts being tracked, the total value of all weights will equal one. As a result, the weighting factor assigned to an analyst for a given performance analysis set is really a distribution number that is evaluated in the context of a set of a plurality of analysts issuing estimates regarding a particular earnings event for a particular security. Importantly, as indicated above, the weighting scheme employed can be controlled and altered by the user. The adjustment and weighting factors described above may be used, together with an analyst's actual earnings estimate, to calculate a custom composite estimate to arrive at a more accurate estimation of a company's earnings. A custom composite estimate is calculated by multiplying an analyst's current earnings estimate (for a given security, time period, and other parameters) by its corresponding adjustment and weighting factors for that given performance analysis set. The results for each estimate for each analyst being studied are then summed to arrive at the custom composite estimate. It will be appreciated that the calculation of a custom composite estimate provides investment managers and similar users with a way of better predicting not only the accuracy of an analyst's earnings estimates but also the actual earnings of a company over any given period of time. As indicated above, a predetermined system database is constructed such that each analyst estimate record in the database contains unique fields related to that estimate. In general, these records contain a combination of data fields present within the Global Analyst Data Object obtained from the FISP and data fields unique to and created within the system of the present invention. Typically, the fields in this restructured database may include an analyst identifier; an event identifier corresponding to a specific security; an event type and date (e.g., Apple, FY-1995 or Intel, Q2-1997); an estimate date; a raw error indicator which corresponds to an analyst's estimate minus the actual earnings for a particular event; other metrics such as the percent error from an analyst's estimate to either the actual earnings or the consensus error; or other error metrics defined by a user. The typical system database record will also contain an Earliness field which contains the number of days by which an analyst's earnings estimate precedes a particular earnings event, such as a company's quarterly or annual earnings postings. This Earliness field can be employed to group estimates of similar Earliness into like Earliness Time Bins. It will be appreciated that this Earliness field or the usage of Earliness Time Bins will likely enhance numerous aspects of the present invention because, in many circumstances, the accuracy of an estimate made shortly before an earnings event is likely to be more accurate than an earnings estimate made months prior to the earnings event. Specifically, each Earliness Time Bin represents a range of days early such that prior analyst estimates may be classified according to particular Earliness Time Bins. For example, one Earliness Time Bin may include all estimates issued by a specified group of analysts for a given security between 7 and 30 days, inclusive, prior to an earnings event or between 31 and 90 days before such an event. In this way, this unique field will allow users to make meaningful and valuable comparisons between analyst estimates for any number of given time periods preceding a particular earnings event. Importantly, in addition to the predetermined data fields discussed above, the database of the present invention may also contain and maintain indices for predetermined data relationships and predetermined analyst performance metrics for a plurality of analysts, such as time series estimates and summary measures of those estimates. Accordingly, by utilizing this restructured database, a user will be able to both rank and analyze the performance of a plurality of analysts based upon any metric. Moreover, based on the data contained in the system database, the present invention allows for the rapid visualization of the analyses of analysts' earnings estimates and buy-sell recommendations. A front-end graphical user interface (GUI) is provided, examples of which are shown in FIGS. 4 and 5. Referring to FIG. 4, the graphical user interface shown contains a plurality of graphical buttons and selection boxes with pull-down menu capability. Preferably, the selection boxes correspond to predetermined fields contained within the system database such as a security identifier or ticker; an analyst; a plurality of event types, such as yearly and quarterly earning postings; earnings event dates; and dates corresponding to Earliness Time Bins. Notably, however, other fields and types of data may be included. Also, the GUI and system allow a user to manually input specific data not initially present in the database for analysis purposes. Manual inputs made by a user are thereafter stored within the system database such that the system may recall and list a user's prior inputs as part of a selection box's pull-down menu of selection alternatives. In this way, the front-end GUI allows a user to easily select from a large number and wide variety of analysis parameters and metrics. According to one aspect of this embodiment, the historical earnings estimates of a single or plurality of analysts may be graphed using the GUI shown in FIG. 4. In this embodiment, a GUI similar to the one discussed above is used except that, in addition to the selection boxes and graphical buttons described above, there are graphical buttons present which allow a user to view a summary of the actual, high, low, and average consensus estimates as derived from the earnings estimates provided by all analysts within the system database. It is anticipated that at least one analyst can be excluded from a calculation using an exclusion function, described further below. Actuating the GUI display of FIG. 4 may generate, for example, the graph shown in FIG. 6. Referring to FIG. 6, it can be seen that the earnings estimates, and revisions of those estimates, of each analyst chosen in FIG. 4 are displayed simultaneously on a graph where the horizontal axis corresponds to a user-determined period of time or Earliness Time Bin, (preferably showing time in days) and the vertical axis plots the range of earnings estimates, (preferably in dollars and cents). More specifically, each analyst's earnings estimates and revisions over time are displayed as horizontal lines corresponding to and level with that analyst's earnings estimate for a particular time period. When an analyst makes a revision to an estimate, whether upward or downward, the change is plotted as a step function with a vertical or essentially vertical line connecting the two horizontal lines representing the difference between an analyst's earlier and revised estimates. The length of each horizontal line equals the number of days, as displayed on the horizontal axis, that the analyst's estimate was at that level. As dictated by a user's selection of analyses inputs from the GUI of FIG. 4, such a graph may also display the high, low, and average consensus estimates along with the estimates of the analysts specified by the user. Additionally, one or more vertical bars showing the actual earnings for the relevant security at specific earnings posting dates may also be displayed. To facilitate reading and interpreting the graph, each analysts' earnings estimate, as well as the high, low, and consensus estimate, and actual earnings bars may be displayed in a unique color. To further facilitate reading and interpreting the graph, a legend box may be displayed simultaneously with said graph which shows the colors associated with each estimate displayed. It will be appreciated that viewing the historical estimates of a plurality of analysts in the manner described above may often provide a context within which an individual analyst's estimates and revisions can be better understood, such as by providing insight into an analyst's estimate revision patterns and the relative accuracy of those revisions over time as they relate to a company's actual earnings postings. As such, this information will likely be valuable in appraising specific revisions made by an analyst to his current estimates, and in deciding whether to act, or to not act, based upon the revisions. According to another embodiment of the invention, the accuracy of analysts' estimates over a single or plurality of time periods, for any given earnings event, can be ranked and visually displayed. Specifically, referring to FIG. 5, a GUI is provided similar to the one shown in FIG. 4. In addition to containing selection boxes and graphical buttons pertaining to a security identifier or ticker, analysts, a plurality of event types, event dates, and dates corresponding to Earliness Time Bins, also included are selection boxes corresponding to the number of estimates made by an analyst; specific analysis metrics, such as raw error or percent error as compared to actual earnings; and average and standard deviation metrics. The information retrieved using the GUI in FIG. 5 may be viewed either as raw, numeric data or, by using a data visualization technique, as a chart, graph, or combination thereof. As shown in FIG. 5, a user can specify a visualization preference by choosing from and actuating a particular GUI button, such as "view chart" or "view data." For example, FIG. 7 shows a bar chart, created by a user actuating the "view chart" graphical button in FIG. 5, illustrating a comparison of the average percent error of a plurality of analyst estimates, made in the 6 to 10 months prior to the end of Apple Computer's fiscal year. Preferably, all those analysts chosen by a user from the GUI of FIG. 5 are displayed simultaneously along the horizontal or y-axis. As shown, the vertical or x-axis displays a measure of the average percent error, both positive and negative, of the estimate of each analyst displayed as compared to the actual earnings for a given security. This visual display allows a user to essentially rank individual analysts by the accuracy of their estimates for a given period of time or Earliness Time Bin, prior to an earnings event, and to identify the analyst(s) with the most accurate earning estimate for a given security, earnings event, and preceding time period. In addition, this visual display clearly illustrates the earnings bias of individual analysts such that, patterns, if any, in an analyst's earnings estimations may be investigated and analyzed. Additional information could also be incorporated into such a graphical display. For example, the vertical axis may display a measure of the average percent error, both positive and negative, of the estimate for each analyst displayed as compared to actual earnings. However, the bar representing and analysts estimate also shows, in addition to the percent error of the analyst's issued estimate, the high and low estimates, or percentile errors estimates (e.g., 90.sup.th and 10.sup.th percentile errors estimates), published by that analyst over the performance analysis set. A black section of an analyst's graphical bar may represent the average error for that analyst. Extending vertically above the black section is a bar segment which ends at a level representing that analyst's high estimate over the performance analysis set. Similarly, extending vertically below the black section of the analyst's bar is a bar segment which ends at a level representing that analyst's low estimate over the performance analysis set. Additionally, an analyst legend box may be displayed for each analyst which may show such information as the number of years an analyst has been providing estimates for the security in question, and the first and last period in which the analyst issued such estimates. In this way, the individual analyst legends may provide further historical context to the historical error performance graph of FIG. 7. These graphs, such as the one in FIG. 7, may be generated by a user designating the performance set for (a) each analyst in list and (b) for each event chosen. Next, the system user fills estimate array with data, for all chosen analysts, to create estimate time series data array--e.g., estimate. After that, the system fills error array, for all chosen corresponding events and dates, to create time series error array--e.g., error. Next the system loops for each event chosen in the performance analysis set back through the previous steps. The system then calculates an error summary metric per analyst--e.g., average error--such as average error, standard deviation, 10 and 90 percent high and low etc. and does so for each analyst. The chart may thus be provided. Similarly, a visual display may also be generated which illustrates a comparison of analysts' performances over not just one but rather a plurality of time periods, as shown in FIG. 8. Here, the Earliness Time Bins chosen by the user are displayed in chronological order, with the most recent time period beginning on the left. The vertical axis displays a measure of the average percent error, both positive and negative, of the estimate of each analyst chosen by a user for analysis. A bar chart is generated wherein each analyst's percent error is indicated by a different color bar. In this way, a user can track a plurality of analysts' earnings estimates over time so as to determine when individual analyst's estimates are more accurate as compared to others. The graph shown in FIG. 9 may also be generated by using the GUI of FIG. 5. Unlike the graphs of FIGS. 7 and 8, which plot the average percent error of analysts' earnings estimates as compared to other analysts for given periods of time, the graph of FIG. 9 displays a scatterplot of the error of a single analyst's estimates relative to the consensus estimate error at the time the analyst's estimates were issued. Here, the horizontal axis shows the number of days prior to the user-defined event, whereas the vertical axis shows the error relative to the consensus error. A value of one on the vertical axis corresponds to an estimate error that is equal to the consensus error. Each scatterpoint represents an estimate or revision made by an individual analyst at a specific date. Although not shown in FIG. 9, vertical lines perpendicular to the horizontal axis may be superimposed on the scatterplot chart to indicate the dates of various earnings events. It will be appreciated that by utilizing such a scatter display, a user may be able to ascertain at a glance which analysts are more likely, either in general or at specific points in time, to publish estimates that are more accurate than the current consensus estimate. Importantly, it should be noted that the graph of FIG. 9 may be used to display a scatter chart of any metric including, but not limited to, raw error, the percent error as compared to actual earnings, or other user-defined errors. In another embodiment of the invention, a user will be able to construct, store, and recall custom composite earnings models for analysis and testing purposes. Specifically, the system will allow for users to create financial transaction models by inputting specific performance analysis sets, including performance metrics and other user-defined metrics and parameters, such as scaling factors, to arrive at specific custom composite earnings estimates. These performance analysis sets and corresponding custom composite estimates may then be stored in the system's database for later retrieval. In this way, a user will be able to test such models by applying them over any previous time period, thereby essentially creating a "virtual analyst" whose hypothetical prospective performance can be compared with the historical performance of a single or plurality of analysts, or even the average historical consensus estimates for any previous time period. Most significantly, it will be appreciated that by conducting such tests a user may be able to refine a model that can be used to accurately predict the accuracy of prospective, analysts' earnings estimates. FIGS. 11a to 11c depict the purpose between the two different types of error calculation. In FIG. 11a, two analysts have made predictions concerning the earnings of a particular security. Their predictions, in dollars, are shown on the y-axis where $.sub.0 is the actual earnings, whereas the time at which the analysts made their predictions is shown along the x-axis. The difference between each of the depicted adjacent markings on the y-axis is equal to $, and the difference between each of the depicted x-axis markings is equal to T. The first analyst initially (t.sub.0) predicted above the actual earnings by $.sub.2, and at time t.sub.1 modified the prediction to an estimate below (-$.sub.2) the actual earning. The second analyst predicted earnings slightly below the actual earnings for the entire period shown. Turning to FIG. 11b, which highlights the error associated with the first analyst's predictions, it is shown that the first analyst has an average error equal to zero because the extent of the overestimate is approximately equal to the extent of the underestimate. This raw error metric is preferably calculated as follows: ##EQU15## By substituting the values shown in FIG 11b, the overestimate is found to be ($.sub.2 -$.sub.0)*(t.sub.1 -t.sub.0) or 2$T and the underestimate is found to be (-$.sub.2 -$.sub.0)*(t.sub.2 -t.sub.1) or -2$T. Accordingly, the first analyst would receive a raw error of 0 and would accordingly be given no adjustment factor. In determining the weighting factor, however, the following equation which represents the absolute error metric, is preferably used: ##EQU16## Again substituting the values for the first analyst, an absolute error of 4$T is found. Applying the same analysis to the second analyst leads to a raw error of -2$T which could in turn be used to calculate an adjustment factor. Similarly, because the second analyst consistently underestimated the actual earnings, the second analyst would have an absolute error of -2$T. Because the absolute error of the second analyst is half as great as the absolute error of the first analyst, the second analyst is preferably assigned a weighting factor greater than the weighting factor of the first analyst. Because analysts start making predictions on a given security at different times, it is possible that a particular analyst will not have made predictions about a particular security for the entire duration over which an error analysis is being performed. In a preferred embodiment, it is possible to make proportional adjustments to various error analysis based on the percentage of time that a given analyst has been tracking a security. Similarly, because analysts start making predictions on earnings at different times, it is similarly possible that certain analysts will not have made earnings estimates at a time when an unanticipated event lead to a significant error. In a preferred embodiment, the effect of such unanticipated events can be filtered by comparing the analysts predictions to a consensus estimate. Such a comparison is termed a relative error metric. The following equation provides an example of a relative error metric: ##EQU17## The relative error metric shows how a particular analyst performed in relation to the other analysts who were tracking a particular security over the analyzed period of time. The purpose of utilizing the actual earnings in the denominator of a preferred embodiment is to enable errors to be normalized so that comparisons can be made across different securities. Because small actual earnings can lead to exaggerated errors, it is possible to establish a minimum actual value, for purposes of this error metric, to prevent such exaggerated errors. For example, if the actual earnings were 0, then any analyst tracking the security would have an infinite error, so a value of, for example, $0.40 could be used to provide useful information from the analysis. In another embodiment of the invention, a user will be able to rank, measure, and analyze the historical accuracy of a single or plurality of analysts' buy-sell recommendations in various ways. As an initial matter, a user will be able to control and otherwise define how recommendation descriptions used by a plurality of analysts are normalized and otherwise translated into scaled recommendation numbers. Specifically, depending on the employer of an individual analyst, said analyst, when either upgrading or downgrading a particular security, will use varying descriptions to make his recommendation. For example, analysts at the investment firm Alex Brown issue recommendations using the following descriptions, predetermined by the firm: strong buy, buy, neutral, source of funds, or sell. In contrast, analysts at the investment firm Goldman Sachs issue recommendations using the following descriptions, also predetermined by the firm: priority list, recommended list, trading buy, market outperform, market perform, and market under-perform. FISPs such as First Call translate and otherwise normalize the recommendation descriptions of the numerous analysts to a scale ranging from 1 to 5, with the following descriptions: 1 (buy), 2 (buy/hold), 3 (hold), 4 (hold/sell), and 5 (sell). The FISPs then calculate an average recommendation by calculating the mean of all analysts' current recommendations as translated to this 1 to 5 scale. In the present invention, recommendation adjustment and weighting factors may be calculated in a way closely resembling that described above for analyst earnings estimates. For example, relatively recent recommendation upgrades or downgrades may be assigned a relatively high weighting factor while older recommendations may receive a weight of zero. Similarly, using these factors an improved custom composite recommendation may be determined which more accurately reflects the action (e.g., buy, sell, hold etc.) that a user should take with respect to a security. In addition, a user will have the ability to control the recommendation normalization process, if so desired, to replace the normalization performed by an FISP. Moreover, using either the FISP generated recommendation scale or user defined scale, a user will have the ability to measure the historical profitability of a single or plurality of analysts' recommendations in much the same way as described above for analyst estimates. For example, using a GUI similar to FIGS. 4 and 5, a user can create a graph illustrating the average percent error of an analyst's recommendation as compared to the average recommendation. Users will also have the ability to create and test portfolio creation rules. Specifically, a user can choose a security and then set up purchase and/or selling instructions that the system will make automatically. For example, a user can instruct the system to purchase a security when a specific analyst issues a recommendation of "2," double his investment if the recommendation is upgraded to "1," and sell all or a certain percentage of the security if and when the analyst downgrades his recommendation to "3" or lower. FIG. 9 provides an example of a scatterplot graph created with the present invention. This scatterplot is generated using the following equation: ##EQU18## where bias error is equal to relative error if relative error is greater than the consensus error. If the relative error is less than the consensus error, then the bias error is assigned a value of zero over the selected time period. The consensus error is calculated the same as raw error is calculated for an individual analyst, except that the consensus estimate is used instead of the analyst's estimate. The bias error is useful in determining how consistently a given analyst or group of analysts outperforms the consensus for a particular security. Another option available in a preferred embodiment is the ability to exclude at least one Analyst. For example, if a particular analyst had an extreme error during a period of analysis that a user is evaluating, then the consensus error might be too reflective of that individual analyst's error. Accordingly, a majority of analysts could have bias errors approximately equal to zero which indicates that they are outperforming the consensus estimate. If a user wants to filter out an analyst's estimate for this or any other reason, it is possible to exclude the analyst's estimate from a particular metric analysis. In a preferred embodiment, there are additional metrics which can be used to evaluate how effectively an analyst acquires and reacts to information. One metric that serves to accomplish this task is the leadlag Factor. Preferably, the leadlag Factor is calculated as follows: ##EQU19## where leads is the number of times that an analyst makes an estimate revision before the majority of the analysts following a particular security, lags is the number of times that an analyst makes an estimate revision after the majority of the analysts following a particular security, and total estimates represents the number of predictions that the analyst has made. In a preferred embodiment, a user can select a leadlag factor based on a number of different variables, including which securities, which analysts, which time periods, which earliness bins, or any combination thereof. Another metric that is useful in predicting how an analyst acquires and reacts to information is the hit percent. A hit percent is an evaluation of the number of times that an analyst successfully revises earnings. In a preferred embodiment, a swing is preferably an estimate that is outside a predetermined standard deviation of the mean of the consensus estimate. In a most preferred embodiment, a predetermined standard deviation of the consensus estimate is approximately 1.5. A hit is preferably a swing in which the analyst's estimate is closer to the actual earnings than the consensus estimate. A hit percent can then be determined by dividing the number of hits by the number of swings, and multiplying the result by 100%. As discussed above, the system may provide the user with the option of viewing a large amount of information in a variety of different formats. According to one embodiment, the user may desire to view contributors to see relationships between stocks, analysts and brokers, as for example, shown in FIGS. 12-14. In FIG. 12, the user may view by analyst, whereby the system presents analysts in the system and enables drilling into each analyst to see which firms they are associated with and which tickers they have followed. In FIG. 13, the user may search for a broker, and the system presents the brokers and enables drilling into the broker to view the analysts that work at the firm and the tickers followed by the analysts and the broker. In another screen, the user may search for a ticker such as a stock. The system may also provide screens through which the user may manage stocks and stock groups against which analysis may be run. The user may do so through stock lists and stock filters. Stock filters may comprise tools for dynamically creating sets that are the result of user defined criteria for picking stocks including security type, country, market cap, P/E, analysts following, and earnings growth. FIG. 14 depicts an embodiment of a screen that enables a user to utilize these tools. A model managing tool may also be provided and screens may be provided to enable users to manage these models. Such screens may comprise those depicted in FIGS. 15-24. A backtest screen used to apply a model to historical data to test the model's accuracy may be provided, such as depicted in FIG. 25. Also, as shown in FIGS. 26-27, historical view screens may be provided. This provides a visual depiction of analyst's estimates over time and may be used to view trends, cluster points, visually backtesting models by placing a smart model that is calculated every N days in the chart as a visual analyst to visually see its performance against the consensus and the other analysts. Also, as shown in FIG. 28, an analysis screen may be provided that presents the impact on the change in estimates and the change in stock prices or consensus estimates. The user may select a time frame to measure these factors, a time bin to analyze the appropriate data sources and a set of stocks to analyze. The application then calculates the answers and presents a chart, such as the one depicted in FIG. 28. A source selector screen may also be provided to enable the user to select sources for performing this analysis. In the analysis, the variables may include the period, start date, price change/consensus change, source, source driving condition, and stock/stock sets to analyze and the sources may include brokers, analysts, clusters, and smart estimates. A performance module may also be provides that enables users to see past performance at the broker, analyst and ticker level. The user may select the prior periods, performance type and error type to view. Other views may also be presented as would be apparent to one of ordinary skill in the art and other embodiments and uses of the invention will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. Accordingly, the specification and examples set forth above should be considered exemplary only. The scope of the invention is only limited by the claims appended hereto.
|
Same subclass Same class Consider this |
||||||||||