IMPORTANT: New Insider & Institutional Ownership Functions

Hello,

We launched a new version of the Insider & Institutional Ownership data to fix several issues that came up since our re-architecture . We are also moving away from snapshotting the data. We now completely rely on S&P for the historical data points which is more manageable. Therefore you might see some backtest differences , but they should be minor. We also re-arranged the reference a bit and consolidated Insider & Institutional Ownership in FUNDAMENTALS->OTHER FUNDAMENTALS-> INSIDER AND INSTITUTIONAL

Now for the good news

  • We kept the old Institutional & Insider factors names unchanged. The naming of these factors is not particularly good nor consistent, but keeping them was safer.

  • We added many new functions that expose new data points, but also give you access to the time series or each datapoint.

  • Please see the new Full documentation for much more.

Let us know of any issues or questions. Thank You

The following are the NEW functions:

[size=1] InsiderBuySh12M(mo_offset) Shares bought by insiders past 12 months (in millions) InsiderBuySh1M(mo_offset) Shares bought by insiders past 1 month (in millions) InsiderBuySh3M(mo_offset) Shares bought by insiders past 3 months (in millions) InsiderBuySh6M(mo_offset) Shares bought by insiders past 6 months (in millions) InsiderBuyTran12M(mo_offset) Buy transactions by insiders past 12 months (in millions) InsiderBuyTran1M(mo_offset) Buy transactions by insiders past 1 month (in millions) InsiderBuyTran3M(mo_offset) Buy transactions by insiders past 3 months (in millions) InsiderBuyTran6M(mo_offset) Buy transactions by insiders past 6 months (in millions) InsiderSellSh12M(mo_offset) Shares sold by insiders past 12 months (negative number in millions) InsiderSellSh1M(mo_offset) Shares sold by insiders past 1 month (negative number in millions) InsiderSellSh3M(mo_offset) Shares sold by insiders past 3 months (negative number in millions) InsiderSellSh6M(mo_offset) Shares sold by insiders past 6 months (negative number in millions) InsiderSellTran12M(mo_offset) Sell transactions by insiders past 12 months InsiderSellTran1M(mo_offset) Sell transactions by insiders past 1 month InsiderSellTran3M(mo_offset) Sell transactions by insiders past 3 months InsiderSellTran6M(mo_offset) Sell transactions by insiders past 6 months InsiderUniqBuy1M(mo_offset) Unique number of insiders buying past 1 month InsiderUniqBuy3M(mo_offset) Unique number of insiders buying past 3 months InsiderUniqSell1M(mo_offset) Unique number of insiders selling past 1 month InsiderUniqSell3M(mo_offset) Unique number of insiders selling past 3 months InstitutionalBuyers(period_offset) The number of investors who purchased shares of the company during the period InstitutionalClosed(period_offset) The number of investors who sold all shares and closed their holding position in the company during the period InstitutionalHolders(period_offset) The total number of investors who own shares of the company InstitutionalNewBuyers(period_offset) The number of investors who opened a new position in the company by purchasing shares during the period InstitutionalPctChg(period_offset) The net shares changed as a percent of shares outstanding InstitutionalPctOwn(period_offset) The percentage of shares outstanding of the company owned by institutional shareholders InstitutionalSellers(period_offset) The number of investors who sold shares of the company during the period InstitutionalShsBought(period_offset) The number of shares of the company purchased by investors during the period (in millions) InstitutionalShsHeld(period_offset) The number of shares of the company held by investors at the end of the period (in millions) InstitutionalShsNet(period_offset) The net number of shares of the company transacted by investors during the period (in millions) InstitutionalShsSold(period_offset) The number of shares of the company sold by investors during the period (in millions) [/size]

Huzzah!

Its good to more functions and factors in this section. It’d be even better to be able to set a minimum size for the deals, and to limit the scope to the CEO and/or CFO.

[quote]
We are also moving away from snapshotting the data. We now completely rely on S&P for the historical data points which is more manageable. Therefore you might see some backtest differences , but they should be minor.
[/quote]I really hope that these changes are minor, because Compustats definition of “point in time” will in theory cause backtests to look better than they were. That’s because Compustat retroactively changes their data to fix their data errors.

Picture this scenario:
Suppose stock ABC had a typo in Compustats data and showed earnings of $10 a share instead of $0.10 a share on February 20, 2018.

What would happen?

Many low P/E strategies which rely on Compustat data would buy it right away in late February, which in turn may have jacked up the price. Portfolio123.com users buy the stock on Monday at an inflated price. Meanwhile, the price falls 50% over next month or so. Alert users will start investigating and find the error. Portfolio123 will report it to Compustat. Compustat in turn will then retroactively adjust the earnings number.

This will cause new backtests to avoid this 50% loss. But live portfolios will be stuck with actual results.

Compustats definition of PIT may be fine for researchers who are interested in the efficiency of the market. But I for one would rather know how well Compustat’s data worked using the numbers they provided at the time.

I just hope that Compustat keeps reducing their error rate which will reduce the severity of this problem.

All:

Chipper6 is absolutely right. One of the issues with Compustat is that they change their “PIT” database whenever they see fit.

Bill

Thanks Marco. The increased granularity over time is good, as well as extending to 12mo to help w/ data continuity.

Yes. Lets hope or even make it our default assumption that CompuStat will do an adequate job on this.

The concern is this. Suppose you faithfully run a port for a year then after a year—with no changes in the sim rules compared to the port–run a sim over the last year (the period covered by the port) so that the port and the sim should look exactly the same. Then simply put: Are the port and the sim the same? And if not how much do they differ?

I wonder if P123 might look at this internally and even consider a public sim/port quantitating the difference. And maybe even defining before—at least internally—how much difference can be tolerated. BTW, I think the biggest difference will be with earnings estimates so this probably should be a heavily weighted factor if this is done.

My guess. I think where will be some differences in the holdings over the year comparing the sim and the port. P123 can decide what “error rate” is acceptable.

My guess from experience a few years back (before snapshots) is there might be some difference in stock picks but even if this is the case it may not make a huge difference in the returns. This difference in the returns (versus the difference in stocks picked) will be more difficult to quantitate as there will be some who will think their sims/ports are more affected by the discrepancy (if there is one). Perhaps, P123 can take some input from the community on this should there be any discrepancies in the stocks held by the sim and the port.

If people in the community want to comment–in say a year–on this I strongly recommend that they run their active ports as they usually would but also put those same ports on auto and make no changes in the auto port. If they make any changes in their active port then they should start a new auto port rather than change the auto port already in existence. P123 should not have to constantly address issues of the difference between a port and a sim where the difference is caused by someone making a small change in a port, forgetting to rebalance on the correct day, someone handling holidays for their port differently than the sim handles holidays, a forgotten discretionary change etc. I have made these types of errors before and hope not to do it again.

I am good with the change and my past experience in real sciences (physics, chemistry, medicine if you can even call that a science) makes me want to accept some reasonable “error rate” on this. That does not make me want to argue against some quality control measures. And as I said, I have no problems if the checks are mostly internal but the community is likely to comment (regardless) and having quantitative data on hand might be in P123’s interest.

In any case what P123 does is much appreciated. For me, it just works. And for me, this includes the use of backtests: even heavily optimized backtests with out-of-sample confirmation (validation). But this will work for the development of new sims (to be validated as ports) only with a certain level of error—preferably a somewhat quantitatively determined error rate (more or less).

-Jim

Well said Jim!

Marco,

looking at this list more closely, it seems odd to me that we have the number of transactions and the number of shares, but not the value of the shares traded. Surely the dollar value of the transactions would be the most significant thing?

Dodge

Jim,

totally random thought on this topic: what % of the market traded on incorrect compustat data, and what % of the market trades on their own data or on the company reported data directly. If everyone trades on unquestioned compustat data then the changes/correction would seem to fall under a different umbrella of concern than if the market trades on their own data that does not contain errors. If the market trades on their own data or on reported data (instead of the incorrect data), I think I’d benefit from historical errors be corrected as our models would seem likely to find stocks that rate suspiciously better than they should - based on the rest of the market knowing better.

I see more data errors than I’d expect given the small pool of stocks I encounter/investigate in ADRs. One out there now seems to be CUK Carnival . Recent period data is loaded into the wrong time field (similar to TTM Tata Motors a short while earlier). The error has been out there for a long time . It’s unclear why repeated errors of this nature would keep showing up, but I’d hope they get corrected.

Michael,

Let me broaden your question slightly. Let me not focus on Compustat or Capital IQ. This is partly because I think actual errors may be minimal.

When I look at the Level II quotes, I am guessing MANY people behind the posted orders know the up-to-date numbers exactly. We hear about readers that read through earnings releases, news etc before humans can get a grasp and buy before a human can interpret the document or news.

Maybe I am not always competing against that. But a morning earnings report before the market opens? A new earnings estimate made after the data was downloaded to P123 computers? Some of the people putting up their limit orders know this and they are probably the ones that have enough money to accept any poorly informed limit order I may make.

It is not the actual errors but the stuff that is not downloaded to P123 before I purchase the stock that worries me. Stuff that is public information but that I do not know–and cannot get through Compustat or Capital IQ until the next day or later–that worries me.

And also, it is at least good to know that when I run a sim the data from Capital IQ may be better than the data I would have had available at the time without checking other publications and data services. I’m not complaining about that. In fact, checking those publications and data services is what I would like to do. I am mostly interested in where, exactly, to get some of that data if it is even possible: even if that information only serves to give me a “no go” on a stock that a P123 port recommends with almost completely up-to-date information.

-Jim