13F Other Included Managers
Which other manager reports a fund's 13F holdings, from the 13F-NT notices managers file when their positions appear on somebody else's report - the link that explains why a large manager can show no holdings of its own. One row per named manager, joined to the reporting manager by 13F file number. Rosters are anchored on the SEC 13F file number, so a pre-2013 text-era entry printed under other numbering is not captured - measured at 1 entry in 208.
edgar_13f_other_managers - the dataset name to pass to the Obscura API.
What one row means
One named relationship on a 13F cover page: manager A's holdings for a quarter are reported on manager B's Form 13F, not on A's own. A `13F-NT` is the SEC form that states exactly this and nothing else - "no holdings are reported in this report, and all holdings are reported by other reporting manager(s)" - so a notice carries no positions and its entire payload is the roster of the other managers it points at. This table IS that roster: one row per (notice, other manager). The notice's own cover row lives in `edgar_13f_filings` under the same `filename`, with `report_type = '13F NOTICE'` and `positions = 0`. It is the edge list of the 13F reporting graph, and it answers the question a holdings table cannot: **why does this manager appear to hold nothing?** A Berkshire subsidiary with $0 of reported 13F positions is not flat - it filed a notice naming Berkshire's file number, and its assets are inside Berkshire's information table. Without this edge, a portfolio built by summing `edgar_13f_holdings` per CIK silently attributes zero to every manager that reports through a parent, and double-counts nothing that would have warned you.
One row per (filename, seq) - one row per other-manager entry on one 13F cover page, `seq` being the entry's zero-based position in the roster as the filer printed it; the parent submission is one row in `edgar_13f_filings` under the same `filename`, and originals and their `/A` amendments are distinct rows (no dedup to one row per (manager, quarter)).
Point-in-time availability
Every Obscura dataset carries available_date: the calendar day the publisher made the row
available, day-of, with no session rounding. It is the one column a backtest filters on, and it means the
same thing on every dataset in the catalog.
For edgar_13f_other_managers: published: available_date is the EDGAR DISSEMINATION day the notice was distributed, taken from the bronze object's own day partition - never the submission's `FILED AS OF DATE`, which SEC back-dates. period_end is the `periodOfReport` quarter-end the relationship is AS OF, stated up to ~45 days before the notice was disseminated, and is never the availability anchor.
Refresh cadence
Obscura refreshes edgar_13f_other_managers every 6 hours - the most frequent scheduled job that re-collects or re-exports it. This is Obscura's own pipeline cadence, not the upstream publisher's release schedule; when a row became public is recorded per row in available_date.
Schema - 12 columns
The full public column list for edgar_13f_other_managers, with the meaning of every field. The same
schema is served unauthenticated at https://api.obscura.trade/v1/catalog/edgar_13f_other_managers.
| Column | Type | Description |
|---|---|---|
| filename | text · not null | EDGAR accession/document path of the notice that printed this roster (e.g. `edgar/data/1584304/0001104659-25-078032.txt`); first half of the composite PK and the join key to the notice's own cover row in `edgar_13f_filings` and to `edgar_filings`. |
| seq | integer · not null | Zero-based ordinal of this entry within the notice's roster, assigned by the order the filer printed it; second half of the composite PK. It is a position, not a rank - the roster carries no ordering semantics. |
| cik | bigint · not null | SEC Central Index Key of the manager that FILED the notice - the one whose holdings are reported elsewhere. Copied from the notice's cover page onto every roster row, exactly as `edgar_13f_holdings.cik` copies the filer down onto every position. |
| available_date | date | Public availability date: the day EDGAR disseminated the notice, so the first day this relationship could be acted on. The point-in-time anchor. |
| period_end | date | Reporting-period end (`periodOfReport`) - the quarter the relationship is AS OF. Stated up to ~45 days before dissemination, so NEVER the availability date. |
| submission_type | text | SEC form type of the notice this entry came from: `13F-NT` original vs `13F-NT/A` amendment. The grain keeps amendments as distinct rows; this is the only column that says which, so a consumer reconstructing a quarter's graph takes the latest `available_date` per (cik, period_end). |
| relationship | text · not null | **WHICH WAY THE RELATIONSHIP RUNS.** `reports_for_filer` - the other manager named in this row reports the FILER's holdings on its own Form 13F. This is the only value written today (a `13F-NT` roster is `otherManagersInfo`, "List of Other Managers Reporting for this Manager"), and it is a stored column rather than an assumption because the sibling roster on a 13F-HR combination report (`otherManagers2Info`) runs the OPPOSITE way - there the filer aggregates the other manager's holdings. Collapsing the two directions into one untagged edge list would invert half the graph. |
| other_manager_cik | bigint | SEC Central Index Key of the OTHER manager - the one whose Form 13F actually carries the filer's positions. NULL when the filer did not state it: the pre-2013 text roster has no CIK column at all, and the XML `<otherManager>` element leaves `<cik>` optional (measured absent on 105 of 237 entries across 2013-2025, not just early filings). Prefer `other_manager_file_number` as the join key. |
| other_manager_name | text | Name of the OTHER manager as the filer wrote it (`<name>`, or the name column of the printed roster). Free text, never a resolved entity - the same institution appears as `Berkshire Hathaway Inc.` and `BERKSHIRE HATHAWAY INC`. XML character entities are decoded, so `Deer VII & Co. Ltd.` is stored as `Deer VII & Co. Ltd.`. |
| other_manager_file_number | text | **THE JOIN KEY**, normalised to the canonical SEC form `028-NNNNN`. A 13F file number identifies a manager's 13F series and is stable across quarters, so this is what reaches the other manager's own filings - `edgar_13f_filings.form_13f_file_number`. Normalisation is load-bearing: filers write the same number as `028-04545`, `28-4545` and `028 - 4545`, and an unnormalised string joins to none of them. NULL when the filer printed no number (measured 6 of 237 XML entries and 1 of 208 text-era entries). |
| other_manager_file_number_raw | text | The file number EXACTLY as filed, before normalisation (`28-4545`, `028 - 14490`). Kept so the normalisation is auditable from the row itself and a future re-normalisation never has to re-read bronze. |
| scraped_at | timestamp with time zone · not null | Internal ingestion timestamp (`Utc::now()` at upsert); the `synced_at`-equivalent for this dataset, EXCLUDED from exports and not a source event time. |
Access edgar_13f_other_managers
Two delivery paths, one identifier. Both require an Obscura account and an active subscription; the catalog entry and the schema above are public.
import obscura
client = obscura.Client("obs_live_…")
df = client.query(
dataset="edgar_13f_other_managers",
symbols=["NVDA", "AAPL"],
start="2024-01-01",
)Create a free account Browse all 122 datasets
Frequently asked questions
What is in the edgar_13f_other_managers dataset?
Which other manager reports a fund's 13F holdings, from the 13F-NT notices managers file when their positions appear on somebody else's report - the link that explains why a large manager can show no holdings of its own. One row per named manager, joined to the reporting manager by 13F file number. Rosters are anchored on the SEC 13F file number, so a pre-2013 text-era entry printed under other numbering is not captured - measured at 1 entry in 208. One named relationship on a 13F cover page: manager A's holdings for a quarter are reported on manager B's Form 13F, not on A's own. A `13F-NT` is the SEC form that states exactly this and nothing else - "no holdings are reported in this report, and all holdings are reported by other reporting manager(s)" - so a notice carries no positions and its entire payload is the roster of the other managers it points at. This table IS that roster: one row per (notice, other manager). The notice's own cover row lives in `edgar_13f_filings` under the same `filename`, with `report_type = '13F NOTICE'` and `positions = 0`. It is the edge list of the 13F reporting graph, and it answers the question a holdings table cannot: **why does this manager appear to hold nothing?** A Berkshire subsidiary with $0 of reported 13F positions is not flat - it filed a notice naming Berkshire's file number, and its assets are inside Berkshire's information table. Without this edge, a portfolio built by summing `edgar_13f_holdings` per CIK silently attributes zero to every manager that reports through a parent, and double-counts nothing that would have warned you.
How do I avoid look-ahead bias with edgar_13f_other_managers?
Filter on edgar_13f_other_managers.available_date, the day the publisher made the row public. For this dataset that date is derived as follows - published: available_date is the EDGAR DISSEMINATION day the notice was distributed, taken from the bronze object's own day partition - never the submission's `FILED AS OF DATE`, which SEC back-dates. period_end is the `periodOfReport` quarter-end the relationship is AS OF, stated up to ~45 days before the notice was disseminated, and is never the availability anchor. A query of the form WHERE available_date <= '<as-of date>' never sees a row before it existed.
In what formats can I get edgar_13f_other_managers?
As a Parquet bulk export (POST https://api.obscura.trade/v1/download) or as JSON from the typed query API (POST https://api.obscura.trade/v1/query), both with dataset="edgar_13f_other_managers". The column schema is public at https://api.obscura.trade/v1/catalog/edgar_13f_other_managers.
Can I filter edgar_13f_other_managers by company or symbol?
Yes. edgar_13f_other_managers carries cik, the column the API's symbols filter resolves against.
How often is edgar_13f_other_managers updated?
Obscura refreshes edgar_13f_other_managers on a every 6 hours schedule - that is the most frequent scheduled job that re-collects or re-exports the table. It is Obscura's own pipeline cadence, not the upstream publisher's release schedule; when the publisher makes a row available is described by the availability rule above, and is recorded per row in available_date.