Sharadar Buyback Ratio for a Stock Split

[BertMacklin]

I am trying to accurately calculate the buy back ratio when a stock split has occurred.

The buyback ratio can be calculated using the formula listed below.

(prev basic shares outstanding - curr basic shares outstanding) / prev basic shares outstanding

Basic shares outstanding can be calculated using the formula listed below.

basic shares outstanding * share factor

The sharadar fields required for these calculations are SHAREBAS and SHAREFACTOR.
period_offset is set to 0 for curr and -1 for prev

When a split occurs there will be a change in SHAREBAS field proportional to the split ratio. This causes inaccuracies in the buyback ratio calculation.

example symbol: UHAL
example sid: FIBBG000BCFXT0
start date: 2022-04-12
end_date: 2023-05-05
split_date: 2022-11-10
split_ratio: 0.1

I am at a loss for how to properly adjust the sharadar fields mentioned above so that the buyback ratio is accurately calculated. In this specific example the buyback ratio should be 0.

Please correct me if I am wrong, but won't this impact any fundamental signal that is compared over time (across quarters / report periods) that normalizes based on shares outstanding (e.g. price to book, price to earnings, prices to sales, price to free cash flow). Maybe the precomputed values like PE1 or PS are doing the correct thing under the hood, but I couldn't get those values to make sense for ADRs because it looked like the SHAREFACTOR wasn't properly accounted for.

FWIW, the field SHARESWA also has this issue.

[Brian]

SHARESBAS and SHARESWA are already split-adjusted, so you shouldn't need to worry about splits to calculate buyback ratio. For example, AAPL had a 4-for-1 split on 2020-08-31, and here are AAPL's share counts for that year, already adjusted:

$ quantrocket fundamental sharadar-fundamentals -i FIBBG000B9XRY4 -m ART -f SHARESBAS SHAREFACTOR SHARESWA SHARESWADIL -s 2020-01-01 -e 2021-01-01 | csvlook
| Sid            |    DATEKEY |      SHARESBAS | SHAREFACTOR |       SHARESWA |    SHARESWADIL |
| -------------- | ---------- | -------------- | ----------- | -------------- | -------------- |
| FIBBG000B9XRY4 | 2020-01-29 | 17,501,920,000 |           1 | 17,660,160,000 | 17,818,416,000 |
| FIBBG000B9XRY4 | 2020-05-01 | 17,337,340,000 |           1 | 17,440,404,000 | 17,618,764,000 |
| FIBBG000B9XRY4 | 2020-07-31 | 17,102,536,000 |           1 | 17,250,292,000 | 17,419,152,000 |
| FIBBG000B9XRY4 | 2020-10-30 | 17,001,802,000 |           1 | 17,352,119,000 | 17,528,214,000 |

Now, in the specific case of UHAL, I do see a one-day drop in the share count on 2022-11-09, and I will investigate that:

$ quantrocket fundamental sharadar-fundamentals -i FIBBG000BCFXT0 -m ART -f SHARESBAS SHAREFACTOR SHARESWA SHARESWADIL -s 2022-01-01 | csvlook
| Sid            |    DATEKEY |   SHARESBAS | SHAREFACTOR |    SHARESWA | SHARESWADIL |
| -------------- | ---------- | ----------- | ----------- | ----------- | ----------- |
| FIBBG000BCFXT0 | 2022-02-09 | 196,077,880 |           1 | 196,077,880 | 196,077,880 |
| FIBBG000BCFXT0 | 2022-05-25 | 196,077,880 |           1 | 196,077,880 | 196,077,880 |
| FIBBG000BCFXT0 | 2022-08-03 | 196,077,880 |           1 | 196,077,880 | 196,077,880 |
| FIBBG000BCFXT0 | 2022-11-09 |  19,607,788 |           1 |  19,607,788 |  19,607,788 |
| FIBBG000BCFXT0 | 2022-11-10 | 196,077,880 |           1 | 196,077,880 | 196,077,880 |
| FIBBG000BCFXT0 | 2023-02-08 | 196,077,880 |           1 | 196,077,880 | 196,077,880 |

If you are seeing a separate unexpected issue with ADRs and SHAREFACTOR, please share an example (and best to create a new thread for it). It's helpful if you can provide a snippet of code so that I can replicate exactly what you're seeing.

[BertMacklin]

Here is the code I am running to display the large change between prev basic shares and curr basic shares.

---

def debug_shareholder_yield(start_date, end_date, dimension, universe_screen):
pipeline = Pipeline(
columns={
"curr_sharesbas" : sharadar.Fundamentals.slice(dimension=dimension, period_offset=0).SHARESBAS.latest,
"curr_sharefactor" : sharadar.Fundamentals.slice(dimension=dimension, period_offset=0).SHAREFACTOR.latest,
"prev_sharesbas" : sharadar.Fundamentals.slice(dimension=dimension, period_offset=-1).SHARESBAS.latest,
"prev_sharefactor" : sharadar.Fundamentals.slice(dimension=dimension, period_offset=-1).SHAREFACTOR.latest,
"divyield" : sharadar.Fundamentals.slice(dimension=dimension, period_offset=0).DIVYIELD.latest,
"report_period" : sharadar.Fundamentals.slice(dimension=dimension, period_offset=0).REPORTPERIOD.latest,
},
screen=universe_screen
)
return run_pipeline(pipeline=pipeline, start_date=start_date, end_date=end_date, bundle=sf.SHARADAR_STOCKS_ONLY)

start_date = "2022-01-01"
end_date = "2023-05-01"
dimension = "ART"

result = debug_shareholder_yield(start_date, end_date, dimension, uni.single_stock("UHAL"))
result

---

The resulting data should show a change in the prev_sharesbas equal to the split ratio. Maybe that one day drop you mentioned is throwing off the prev_sharesbas? I say this because I ran the same code over a date range that includes the split for AAPL and did not notice the same issue. I also ran the same code for symbol ELP (also had a 10:1 split). I did not see the same problem. However, for ELP there is an absolutely MASSIVE jump in curr_sharesbas (2022-04-01 --> 2022-05-01). My only guess is that this is a secondary offering because it does not coincide with its split date.

[Brian]

The jumps in SHARESBAS (and related fields) for UHAL and ELP have now been corrected. Please run collect_sharadar_fundamentals again to pull down the corrected data.

ELP underwent an ADR ratio change which had not been reflected in the data, causing the jump in SHARESBAS. Sharadar has now corrected that issue. The UHAL drop had already been corrected by Sharadar but due to a separate issue on QuantRocket's end (now fixed), the change had not been properly synced over.

[BertMacklin]

I can confirm that UHAL and ELP are now correct.

Unfortunately, the more I dig into the data the more extreme cases I find. I wrote a rather crude script to try and dig out all of the obviously extreme cases for buyback yield roughly > abs(60%).

WULF, NWTN, RTC, NAAS, FLJ, NUTX, SOUN, SOS, SGHC, PROK, AADI, BOWL, GBTG, KNTK, GETY, WBS, ITCL, BTWN, HZON

[Brian]

Do you have examples where you have reason to believe the data is wrong, other than based on a buyback yield screen? Your screen is inherently going to surface every big jump in shares, but that doesn't necessarily indicate a data error. I spot-checked several of these and what I see looks like the inherent complexity of equities data rather than data errors. A lot of these symbols are SPACs and the jumps in shares occurred around the time they deSPACed. Calculating buyback yield on those is probably asking for trouble. NUTX is a penny stock that merged with another penny stock resulting in many more shares than before, so the data seems right, even if it makes the buyback yield misleading. All but a few of these examples have very negative buyback yields, indicating large increases in shares, but that can legitimately happen for a variety of reasons. The only extremely positive yields I see in this list are for a couple of illiquid SPACs.

When you find something that looks goofy in the data, a good place to start is to research specific examples (press releases, EDGAR filings), then refine your pipeline accordingly to exclude things you don’t want. For example, you could exclude most current SPACs with an industry filter and you could exclude most deSPACs with a filter requiring a minimum length of quarterly history. If that process reveals suspected data errors, report them accordingly.