A manager who filed a full holdings report last quarter files a notice this quarter, and your holdings table for them goes empty. If the loader was written by somebody treating 13F as a single form type, that empty row propagates as a complete liquidation. Every position the manager held is now recorded as sold in the quarter, at quarter-end prices, in whatever attribution or crowding model sits downstream of the table. Nothing was sold. The positions moved to a different filer's report.
This is the most common structural error in 13F ingestion, it is silent, and it fails in the direction that produces the most exciting signal, which is why it survives so long before anyone catches it.
What the notice actually says
Form 13F is not one document. The cover page carries a report type, and the three you will encounter are a holdings report, a notice, and a combination report. Amendments to any of them arrive with their own type marker.
A holdings report carries the information table. A notice carries none, and that is the design, not a defect. The manager is telling the Commission that they did exercise investment discretion over reportable securities during the period and that all of those holdings are being reported on a holdings report filed by another manager. The notice exists so that a filing obligation is discharged visibly rather than by silence, and so that the reader has a pointer to where the positions actually live.
A combination report is the hybrid. Some holdings are reported in its own information table, and the remainder are reported by another manager. Both the notice and the combination report carry a list of the other reporting managers on the summary page, with their file numbers. That list is the cross-reference, and it is the piece most loaders never read.
The distinction in that caption is not pedantry. Form 4 transactions are self-reported by officers and directors within days. Form 13F is a quarter-end snapshot filed by managers up to forty five days later, and it is the only one of the two where a filer can legitimately submit a document containing no positions at all while still holding positions. If your ingestion code shares a schema across both, the report-type column has to be on every row.
The two errors a naive loader makes
The first is the phantom liquidation. The loader computes quarter-over-quarter deltas by joining the current period's rows to the prior period's rows on filer and security. A notice produces no current rows. Every prior row therefore falls out as an exit. If you run a strategy or a research screen that looks for large institutional exits, this filer will top it, every time, and the finding will look robust because the dollar value is real and the manager is real.
The second is the disappearing manager. A loader that builds its filer universe from whoever submitted an information table this quarter will drop the notice filer entirely. That is less dangerous than the phantom liquidation because it is closer to being correct, but it corrupts anything that depends on a stable panel of filers. Coverage counts drift. A crowding measure that expresses ownership as a fraction of tracked managers moves because the denominator moved. Backfills and live runs disagree, and the disagreement is not reproducible unless you kept the report type.
Both errors have the same root cause, which is treating absence of data as data. A notice means unknown-here, not zero. Those are different values and they need different storage.
Where the double count enters a filer family
Now the harder half. Large asset managers file as families. A parent entity and a set of advisory subsidiaries each have their own identifier, each has its own filing obligation, and the family decides how to discharge them. There are two legitimate structures.
In the first, one entity files a combination or holdings report covering the whole family, and each other entity files a notice pointing at it. In the second, each entity files its own holdings report for its own book. Both are compliant. They produce very different data.
The double count arrives when the family switches structure, or when a loader sums across the family without checking who reported what. If the parent's information table already includes the subsidiary's positions, and the subsidiary also has rows in your table from a period when it filed separately, then a naive aggregation to family level counts those positions twice. Aggregate assets under management for the family inflates. Ownership as a percentage of shares outstanding can exceed what is plausible, and if it exceeds one hundred per cent you at least get a visible symptom, which is lucky. Usually it does not, and you simply carry a book that is too large.
The information table itself gives you the tool. Rows carry a column identifying other managers with a discretion interest in the holding, keyed to the sequence numbers on the summary page's list of other included managers. That column plus the report type is enough to build a correct aggregation, and without them the aggregation is guesswork.
A loader contract that survives an audit
Five rules, and they are cheap to implement if you do it before the history is loaded rather than after.
- Store the report type on every filing record, and store it on every position row too. Denormalising it onto the rows costs almost nothing and it means no downstream query can accidentally forget.
- Represent a notice period as an explicit no-data state for that filer, distinct from a zero holdings state. A filer that genuinely reports an empty book is rare but it exists, and it means something different.
- Never compute a delta across a report-type change. If the prior period was a holdings report and the current period is a notice, the correct delta is undefined. Emit a flag, not a number. The same applies in reverse, where a filer moving from notice to holdings report will otherwise look like it built an entire book from nothing in one quarter.
- Parse the other-managers list from the summary page and persist it as edges, not as text in a blob column. This is the only thing that lets you resolve a family correctly, and it is also what lets you answer the question of whose report a given position is really sitting in.
- Choose one aggregation key and document it. Aggregating to the reporting manager who actually filed the table is defensible. Aggregating to the family is defensible if you deduplicate by the other-managers edges first. Aggregating by summing every entity with the same brand string is not defensible and it is what most quick scripts do.
What you say in the review when the numbers change
The reason to fix this before it matters is that the correction is not cosmetic. When you add report-type handling to an existing loader, historical deltas move. Positions that your research recorded as exits become no-change or unknown. Anything calibrated on those deltas needs recalibrating, and if the strategy was sized on a signal that included phantom liquidations, part of its historical edge was a parsing artefact.
That is a survivable conversation if you can produce three things. A dated statement of what the loader did before and after. A count of affected filer-periods, which is a small number that sounds much better than a vague admission. And a point-in-time guarantee going forward, meaning your table records what was knowable on each date rather than what the current version of the parser thinks the past looked like.
The point-in-time property is the one worth defending hardest. Amendments to 13F filings arrive weeks and sometimes months after the original, and a restated filing can turn a notice into a holdings report retroactively. If your table silently overwrites the original with the amendment, every backtest you run reads a version of history that was not available on the trade date. Keep both. Key on the filing accession rather than on the period alone, and let the research layer choose whether it wants as-filed or as-restated. An allocator asking how you handle restatements is asking whether you understand that the data set has a time dimension of its own, and the answer needs to be a schema, not an assurance.