institutional-portfolio-13f

ZipLime Institutional Fund Portfolios (PIT)

[!CAUTION] A 13F is stale by construction. It reports a quarter that ended up to 45 days earlier, and amendments restate it for months afterwards — the longest in this dataset arrived 452 days late. Use knowledge_date, never event_date, to decide what a strategy could act on.

Every Form 13F holdings report filed with the U.S. SEC since structured filing began, turned into point-in-time portfolios: what each institutional manager held, as it became known, and what every manager together held of each ticker.

The deterministic recipe lives in recipe/ in the same repository and revision as the published data. Nothing here was assembled by hand — see PIPELINE.md for the method, including the parts that are approximate.

Configs

Covering 2013 Q2 to 2026 Q2 across 16,538 managers, current to the last filing accepted on 2026-09-29.

Every table is partitioned by the UTC year of its knowledge time, knowledge_year=YYYY/. A backtest over the first half of 2024 needs the 2024 partition and, for the portfolios known on 2 January, the 2023 one — it never needs the rest. Inside a partition files are sorted by ticker (holdings: by CUSIP), then knowledge time, so a reader asking for a handful of tickers opens a few row groups.

from datasets import load_dataset

features = load_dataset("ZipLime/institutional-portfolio-13f", split="train")  # default config

import polars as pl

# Only the 2024 partition is read, and only these tickers' row groups.
features = pl.scan_parquet(
    "hf://datasets/ZipLime/institutional-portfolio-13f/data/features/knowledge_year=2024/*.parquet"
).filter(pl.col("ticker").is_in(["AAPL", "MSFT"])).collect()

# The point-in-time table, with exact dtypes, through its Delta log.
positions = pl.scan_delta("data/positions/fund_portfolios.delta")

Pin a repository revision for a reproducible research result.

The one thing to know before backtesting

A 13F tells you what a manager held at a quarter end, not what they hold. The gap is structural and large:

quarter ends 30 Jun  ->  report due 14 Aug  ->  amended into November

On 1 August you are still holding the March portfolio. Between 14 August and 14 November you hold June's. Median disclosure lag in this dataset is 45 days; amendments run to a median of 135 days and a maximum of 452.

Two consequences the data itself carries:

• Confidential treatment hides positions, then reveals them. A manager can ask the SEC to withhold a position while it is being built; when the request expires the position appears in a NEW HOLDINGS amendment months later. Berkshire's Q1 2025 report showed 36 positions when filed and 39 after the 14 August amendment. Query at the earlier date and the withheld position is correctly absent.
• Only long US-listed equity is here. No shorts, no cash, no bonds, no foreign listings. For Berkshire that means the Japanese trading houses and the operating businesses are invisible; this is the US public equity book, not the company.

Features — the default config

One row per ticker and UTC day on which any manager's report changed what was known about it, carrying the aggregate over every manager for the current reporting quarter as known at knowledge_date. The current quarter on a day is the last quarter that ended before it: from 1 April to 30 June a row describes the March quarter, however few managers have filed it yet.

A manager that has not filed yet is never read as a seller: the quarter-on-quarter columns compare a manager only once its report is in. Amendments and restatements arrive on the day they were filed. Aggregates are kept to three significant figures and pct_reported to whole percentage points so the whole config stays near 100 MB; the exact figures are in positions. Only long equity (no puts or calls) mapped to a ticker is counted.

Managers — one book per curated manager

features adds every filer together, so it cannot say what Berkshire just bought; positions can, but it is an event stream a hosted strategy cannot filter, and turning it into a book is the revision replay where look-ahead creeps in. managers does that replay once, for the 28 managers in recipe/managers.py, and publishes the result.

Every time a manager's known book changes -- a 13F-HR, a restatement, a confidential position revealed by a NEW HOLDINGS amendment -- the whole book of its latest reported quarter is published again, stamped with the acceptance time, plus an EXITED row for each position the previous quarter held and this one does not. The newest rows of a manager are its book.

Each snapshot also carries one row on SPY with status == "SNAPSHOT". A hosted strategy reads a dataset only for the instruments it names; reading SPY with its universe tells it which snapshot is a manager's newest even when every position falls outside that universe. Share-class tickers the security master writes without a separator (BRKB) are published a second time in dotted form (BRK.B) under the same CUSIP, so the spelling the asset database uses resolves; keep one row per manager and CUSIP. Books of thousands of positions (Renaissance, Citadel, D. E. Shaw, Two Sigma, Point72, Millennium) are cut to their 500 largest after ranking the whole book.

The strategy catalogue built on this config -- one template, catalog/strategy_13f.py, and thirty parameter sets in catalog/strategies.json such as Buffett New Buys or Legends Portfolio -- ships in the same revision. A 13F shows long U.S. equity only: these are strategies based on disclosed holdings, not reconstructions of any manager's portfolio or trading.

Point-in-time view

data/positions/fund_portfolios.delta is the table a ziplime bundle mounts. It is a Delta table partitioned by knowledge_year; every file in it is live, so reading knowledge_year=*/*.parquet directly gives the same rows. manifest.json describes it: bundle_storage_data.table_uri points at the table and schema lists its columns exactly as the files carry them.

system   entity_id, event_date, knowledge_date, knowledge_estimated
values   manager_cik, manager_name, cusip, ticker, issuer_cik, match_confidence,
         issuer_name, title_of_class, put_call, shares, value_usd, weight_pct,
         portfolio_value_usd, position_count, rows_aggregated, disclosure_lag_days,
         was_confidential, value_flagged, accession_number, logical_position_id,
         revision, supersedes_position_id, amendment_status, inserted_at

entity_id is the security, by CUSIP; ticker is the ticker it traded under on the knowledge date (manifest.json → entity_column: ticker). The manager holding it is manager_cik. Tickers come from cusip_map in ZipLime/security-master at the revision manifest.json → security_master.revision pins: a row takes the ticker whose first_seen … last_seen interval holds its knowledge date, so 30303M102 is FB before June 2022 and META after. 96.4% of holding rows and 97.3% of their value carry a ticker; match_confidence grades the CIK match behind it.

The as-of query has three steps and the order is load-bearing:

import polars as pl

positions = pl.scan_delta("data/positions/fund_portfolios.delta")

# 1. Restrict to what was knowable at the simulation timestamp.
visible = positions.filter(pl.col("knowledge_date") <= simulation_time).collect()

# 2. Resolve revisions: the newest state of each logical position.
latest = visible.sort(
    ["logical_position_id", "revision", "knowledge_date", "position_event_id"]
).unique(subset=["logical_position_id"], keep="last", maintain_order=True)

# 3. Only now drop what is no longer in force.
portfolio = latest.filter(pl.col("operation") == "UPSERT")

• Filtering by knowledge_date first keeps an amendment filed after simulation_time from deciding which row survives.
• Sorting by revision before knowledge_date matters because an estimated knowledge date is an upper bound, pushed to the end of the filing day.
• Dropping non-UPSERT rows last matters because a retraction is itself a revision; filtering it out earlier resurrects the position it retracted.

recipe/build_positions.py implements exactly this as as_of(positions, at, manager_cik=...), which also picks the latest quarter the manager had reported by that moment and recomputes weights on the resolved set.

Amendments

A 13F-HR/A states which kind it is, and the two are not interchangeable:

Treating one as the other either drops most of a portfolio or double counts it. 22,060 position events come from amendments that declare no type; pass include_unresolved=True to see them.

Reporting units — the largest trap in this data

Form 13F reported holding value in thousands of dollars until an amendment required whole dollars for filings made from January 2023. Filers adopted that on their own schedule: Renaissance Technologies was still filing in thousands six quarters later, and 622 of 10,117 filers were in mid-2024.

A filing read in the wrong unit is wrong by a factor of a thousand while every weight in it stays correct, so nothing downstream notices. The unit is decided from three signals, strongest last: the filing's own implied prices (value ÷ shares, including filings that type every share count PRN); the manager's own value history; and every other holder's price for the same CUSIP that quarter, which overrules the other two wherever it can compare enough rows. 3,362 filings had their unit changed, listed with the pass that changed them in quality/unit_corrections.parquet. value_usd everywhere is in dollars under the decided unit; value_reported_units says what the filer must have used.

What the passes do not settle is flagged, not silently decided: 735 filings in quality/filing_flags.parquet, and 349,919 holding rows priced ten times or more off every other holder of the same security. Both reach positions as value_flagged. Filter on value_flagged before summing notional across managers.

Coverage and known gaps

Other things worth knowing:

• 13F-NT are notices. They report that a manager has nothing to disclose, are kept in filings, and produce no positions.
• 14,470 filings (4.5%) disagree with the totals their own cover page declares. Filers copy a previous quarter's summary or miscount by one; the filed rows are kept and the disagreement is published in control_rows_delta.
• 66 filings put share counts in the value column. Flagged value_quality = "value_equals_shares", values unusable.
• Reports on quarters before 2013 Q2 appear: 1,219 filings from 265 managers, made in the structured format years later — Smith Affiliated Capital filed its 2010–2013 reports in 2015 — or with a mistyped period. They are kept as filed and are not counted as coverage.
• A quarter is not a holding period. Anything bought and sold inside one quarter never appears at all.

Using it with ziplime

hf://ZipLime/institutional-portfolio-13f mounts features by default. manifest.json declares what a reader needs: default_config, entity_column: ticker, partition_column: knowledge_year, the knowledge_date and event_date columns, a schema per config generated from the files themselves, and for the point-in-time bundle data_type: PIT_DATA, the storage class and bundle_storage_data.table_uri. A backtest window reads only the partitions its knowledge dates fall in.

Not every manager's 13F is a portfolio worth cloning. recipe/managers.py carries a curated registry with a representative flag and the reason: a long-only concentrated book like Berkshire's is substantially the whole position, while a multi-strategy platform's long equity slice is a fragment of a hedge whose other legs are not filed, and a quantitative shop's quarter-end snapshot is not a portfolio anyone held.

How the data was verified

Every published figure comes from the filing it cites; nothing is inferred by a model. The checks that carry the most weight are documented in PIPELINE.md:

• Two independent sources agree. History is loaded from SEC's quarterly Form 13F Data Sets, but the same filings were also parsed one by one from their XML. On the overlap the two routes produced 25,366 identical positions — zero disagreements in shares, zero in value once the unit normalisation is applied.
• Acceptance time is read, not taken on trust. It comes from each submission's SGML header, which is stamped in Eastern time and converted here. EDGAR's submission index was checked against those headers on 972 filings: 118 (12%) disagreed, every one by exactly four or five hours — Eastern time labelled UTC, in the direction that creates look-ahead. The index is not used.
• Prices are checked against the market. Every filing's implied prices are compared with every other holder's for the same CUSIP and quarter; the units follow from that wherever it can be measured.
• A daily run equals a full rebuild. The position table is appended to, and a test asserts the appended events are exactly those a full replay produces.
• Publication gates. recipe/quality.py runs before every publication and fails the build on duplicate event IDs, negative values, non-monotonic revisions, a systematic rate of unit discontinuity, any file whose columns differ from the declared schema, and unflagged value priced above $5,000 a share against its other holders. This revision passes all of them (data/quality_report.json).

Updates

Runs execute on Hugging Face Jobs from jobs/run.py, a self-contained UV script stored in this repository, so the code that produced a revision ships with that revision. The order is fixed:

restore -> lint -> tests -> update -> append positions -> features -> validate -> publish

Nothing is uploaded unless every gate before it passed, so a broken run leaves the previous revision as the latest valid release. A run adds one update-<UTC stamp>.parquet per table and knowledge year it touched and rewrites only the current years of features; it never rewrites a published row of the raw tables or the position table, and publishing deletes from the Hub whatever the run no longer holds, so no file of an earlier run lingers. A full rebuild — a new layout, unit rule or security-master revision — is published as a revision of its own.

New submissions are found through EDGAR's quarterly index — one request enumerates a quarter — and only those not already stored are fetched.

License, source terms, and disclaimer

The ZipLime-authored recipe, documentation, schema and database compilation are offered under the Apache License 2.0, to the extent ZipLime has rights to license them. The underlying filings are created by institutional investment managers and made available through SEC EDGAR; this project does not claim that those filings are U.S. Government works. Source URLs and accession numbers are retained on every row for verification. See NOTICE for scope.

CUSIP identifiers appear as filed in public SEC documents. CUSIP Global Services asserts rights in the CUSIP database; consider whether your use requires a licence from them.

Use of SEC systems must follow its developer resources and Fair Access guidance. This dataset is provided for research, without warranty. It is not investment advice, and the extraction is imperfect in the ways documented above.