A consensus figure looks simple. One number for next year's earnings per share, perhaps with a range around it. Behind that number sits a series of decisions: which forecasts count, how they are lined up against each other, and what happens to the one that sits a long way from the rest. Each decision changes the result, and anyone relying on it, whether a fund manager, a data team or an AI agent writing a morning brief, should be able to see them.
This piece sets out how Research Protocol computes cross-broker consensus today, from the forecast a broker publishes to the figures a reader sees.
Step 1: each broker's forecasts, in its own structure
Brokers do not model companies the same way. One analyst's EBITDA is before IFRS 16 and another's is after. One publishes net cash and another net debt. One reports in millions and another in billions.
So the hub does not squeeze forecasts into one template on the way in. A provider publishes its forecasts in its own line items, as JSON through the REST API, as CSV or as RIXML, and each line item keeps the name and definition the analyst gave it. A reader entitled to that provider sees the model as it was built.
Consensus still needs a common reference, so each provider's template maps its own line items to a fixed set of canonical metrics: revenue, EBITDA, EBIT, adjusted EPS, reported EPS, dividend per share, net debt, free cash flow, target price and rating. Each template maps exactly one line item to each canonical metric. A mapping can carry a scale factor, for a provider that publishes in billions where the reference is millions, and a sign flip, for a "net cash" line that contributes to net debt. A provider can run more than one template, say one for companies it models before IFRS 16 and one for after, and choose which applies company by company.
Step 2: which forecasts count
For each company, metric and period, the hub gathers one contribution from each broker that covers it.
- The current version only. When a broker revises a forecast, the new figure supersedes the old one. Superseded figures stay in the revision history but never feed consensus.
- No older than 180 days. A forecast counts only if its as-of date falls within the last 180 days. Older forecasts are kept, but they drop out of consensus. A daily pass makes sure a forecast leaves within a day of reaching that age, even for a company nobody has published on since.
- Estimates and actuals apart. Estimates, actuals and preliminary figures are separate streams, so a screen of estimates never mixes in reported numbers.
- Each period on its own. Annual, half-year, quarterly and monthly figures each have their own consensus, keyed by fiscal year and period.
Step 3: one currency
A median of figures in sterling and in dollars is not a meaningful number. The hub takes the most common currency among the contributions for a metric and period, and computes the statistics in that currency only. Where two currencies are equally common, the alphabetically first wins, so the result is the same on every run.
Contributions in other currencies are not hidden. They are counted in the contributor total, and the hub reports a second count alongside it: the number of contributions actually behind the median. When the two counts differ, a reader can see that part of the market has been left out of the statistics.
UK per-share figures get one extra step. Where some brokers quote a figure in pence and others in pounds, the hub converts the pounds figures to pence and treats them as one currency, so 50p and £0.50 are counted together rather than as two separate views.
Step 4: the statistics
With the contributions in one currency and on one scale, the hub calculates:
- the median, the middle forecast, which a single extreme estimate cannot drag about the way it drags an average
- the mean, the minimum and the maximum
- the standard deviation, treating the contributing brokers as the whole population rather than a sample, once there are at least two contributors
- the interquartile range, once there are at least four
The quartiles use linear interpolation, the same method as Excel's PERCENTILE function, so a data team can reproduce them from the underlying forecasts. The arithmetic is done in decimals rather than floating point, so the same inputs give exactly the same outputs every time.
Step 5: outliers are flagged, not removed
From the interquartile range the hub sets two bounds: 1.5 times the interquartile range below the first quartile, and 1.5 times above the third. This is the standard Tukey rule. A forecast outside those bounds is an outlier.
Outliers are not deleted. They still count towards the contributor total and still show in the minimum and maximum. The median already limits how far one forecast can move the central figure, and the bounds tell a reader which forecasts sit outside the main body of opinion. A broker with a contrarian view may be the one that turns out to be right, and removing it would hide exactly the information a careful reader wants.
With fewer than four contributors the hub sets no outlier bounds at all. With two or three forecasts, quartiles say very little, and a rule that branded one broker in three an outlier would mislead more than it would help.
Step 6: ratings
Ratings are counted rather than averaged. The hub records how many brokers hold each rating, using the label each broker publishes. It does not currently translate one firm's "outperform" into another's "buy", so the distribution shows ratings in the brokers' own words, and two brokers saying much the same thing in different terms appear as separate entries. Rating consensus is only computed on estimates.
Step 7: keeping it current, and keeping the history
Consensus is recomputed when a broker pushes new forecasts, when a provider changes a mapping or a template, and once a day so the 180-day window keeps moving. When a recompute produces different figures from the last ones recorded, the hub adds a point to the consensus history, so a reader can see how the view on a company has moved over time and not just where it sits today. A recompute that changes nothing adds nothing.
Who sees what
Not every figure is equally public.
- Anyone can see the headline figures: median, mean, minimum, maximum, the number of contributors and the currency.
- Signed-in readers also see the standard deviation, the outlier bounds and the rating distribution.
- Readers entitled to a contributing broker see that broker's own forecasts next to consensus, with its revision history, for the brokers they are entitled to and no others.
The same rules apply whichever way the question arrives. The REST API serves consensus, per-broker forecasts and history for a company. An AI agent can call get_consensus, compare_brokers and get_consensus_history on the MCP server, and the rpt command-line tool has the same reads.
Why the method matters
Two consensus figures for the same company can disagree simply because they were built differently: a different window, a different treatment of currencies, a different rule for outliers. None of those choices is wrong in itself. The trouble starts when nobody can see which choices were made.
Publishing the method, and showing the counts behind each figure, lets a reader decide how much weight to put on a number. An agent can check whether a median rests on twelve brokers or on three before it quotes it to a portfolio manager.
If you are building an agent that needs cross-broker consensus, get a free key and call get_consensus. If you run research at a broker and want to see how your forecasts would sit in it, email [email protected].