Form 40-17F1 Files Dataset

The Form 40-17F1 Files Dataset is a longitudinal collection of EDGAR submissions of form type 40-17F1 and its amendment 40-17F1/A — the certificate of accounting filed under Rule 17f-1 of the Investment Company Act of 1940. Each record represents one custody-verification event: a single independent public accountant's certificate concerning portfolio securities held by a registered management investment company at a member of a national securities exchange, packaged together with the structured EDGAR submission metadata. The filer of record is the registered fund (typically an open-end or closed-end fund), but the substantive document inside is signed by the independent accountant retained to perform the examination. The dataset spans from February 1998 to the present, is delivered as monthly ZIP containers in TXT, JSON, and HTML, and covers the full population of EDGAR 40-17F1 and 40-17F1/A submissions.

Dataset APIs

Dataset Files

What This Dataset Contains

The dataset captures every EDGAR submission of form type 40-17F1 and 40-17F1/A and packages each one as a per-accession folder containing the structured submission metadata together with the substantive document(s) the filer transmitted. The form has two names that any parser will encounter: Form N-17f-1 is the legal title printed inside the document — its full caption is "Certificate of Accounting of Securities and Similar Investments of a Management Investment Company in the Custody of Members of National Securities Exchanges, Pursuant to Rule 17f-1 [17 CFR 270.17f-1]" — while 40-17F1 is EDGAR's transmission form code for the same submission, with 40-17F1/A for amendments. A text search inside a record will hit "FORM N-17f-1" in the document body, while every metadata-side identifier (folder names, formType, documentFormatFiles[].type, the description string) uses 40-17F1. Both labels are aliases for the same filing.

The legal substance behind the document is Rule 17f-1 under the Investment Company Act of 1940: a registered management investment company that places portfolio securities with an exchange-member custodian must engage an independent public accountant to verify those holdings by actual examination at least three times per fiscal year, with at least two examinations on dates chosen by the accountant without prior notice to the custodian. The certificate filed on this form is both the accountant's attestation of that examination and the registrant's compliance evidence that the periodic verification mandated by the rule has been carried out.

The dataset is delivered as monthly ZIP archives. Containers for this form type are small; 40-17F1 is a low-volume filing, and a typical month yields a handful of accession folders rather than thousands. Earliest sample data extends back to February 1998, and the file types found in the dataset are TXT, JSON, and HTML.

Content Structure of a Single Record

What one record represents

One record in the Form 40-17F1 Files Dataset is a single EDGAR submission of form type 40-17F1 or its amendment 40-17F1/A, identified by an SEC accession number and materialized on disk as a per-accession folder that bundles the structured submission metadata together with the substantive document(s) the filer transmitted to EDGAR. Each record captures one custody-verification event: a single accountant's certificate of examination filed by, or on behalf of, a registered management investment company concerning securities held in custody by a member of a national securities exchange.

Container layout on disk

Decompressing one monthly ZIP yields a single top-level folder, and inside that folder every 40-17F1 submission filed during the calendar month is stored under its own per-accession subfolder:

          1
          YYYY-MM.zip
        

          2
            └── YYYY-MM/
        

          3
                  ├── <accessionNoDigits>/
        

          4
                  │     ├── metadata.json
        

          5
                  │     └── <filerSlug>_40-17f1.htm
        

          6
                  ├── <accessionNoDigits>/
        

          7
                  │     ├── metadata.json
        

          8
                  │     └── <filerSlug>_40-17f1.htm
        

          9
                  └── ...
        

Naming conventions:

• Container: YYYY-MM.zip, mirroring the year/month hierarchy (form-4017f1-files/YYYY/YYYY-MM.zip) used by the source API.
• Top-level folder inside the ZIP: YYYY-MM/, matching the container period.
• Per-filing folder: the 18-digit EDGAR accession number with dashes removed (e.g. 0001580642-25-001585 -> 000158064225001585).
• Per-filing files: a fixed-name metadata.json plus one or more document files preserving the original EDGAR filenames the filer chose (commonly of the form <filerSlug>_40-17f1.htm, but the slug and casing vary by filer and there is no enforced naming pattern).

What sits inside a per-accession folder

Each accession folder has two structural layers:

1. metadata.json — a flat JSON object describing the EDGAR submission envelope (form type, accession, dates, links, filer/subject entities, and the original document manifest). Always present, always under this exact filename.
2. One or more document files — the substantive document(s) extracted from the original SGML submission. For 40-17F1 this is normally a single .htm file carrying the certificate text, with its filename carried over verbatim from the EDGAR submission (for example <filerSlug>_40-17f1.htm). If a filing happens to include additional non-image documents, all of them are present.

Image files (image_*.jpg, scanned signatures or letterhead graphics) and the complete-submission SGML wrapper (<accessionNo>.txt) are listed in metadata.json.documentFormatFiles[] but are not physically packaged in the ZIP. See "Excluded content" below.

The metadata.json envelope

metadata.json is a flat JSON object with the following top-level fields:

• formType — EDGAR form code, either 40-17F1 or 40-17F1/A.
• accessionNo — SEC accession number in dashed form (NNNNNNNNNN-NN-NNNNNN); the same number, dashes removed, names the parent folder.
• effectivenessDate — date-only YYYY-MM-DD representing the filing's effective date.
• filedAt — full ISO 8601 timestamp with timezone offset, recording the moment EDGAR accepted the submission.
• description — human-readable form description, typically "Form 40-17F1 - Certificate of accounting of securities in custody of management investment companies [Rule 17f-1]".
• linkToFilingDetails — URL of the primary form document on www.sec.gov.
• linkToTxt — URL of the complete SGML submission text file (<accessionNo>.txt).
• linkToHtml — URL of the EDGAR filing index page (<accessionNo>-index.htm).
• linkToXbrl — URL of XBRL data; consistently an empty string for this form type.
• id — 32-character hexadecimal identifier assigned by the data provider, stable per record and distinct from the EDGAR accession number.
• documentFormatFiles[] — manifest of every document the original SGML submission contains (described below).
• entities[] — EDGAR entity records associated with the submission (described below).
• seriesAndClassesContractsInformation[] — array of fund series/class metadata; consistently empty for this form type.
• dataFiles[] — array of supplementary structured data files; consistently empty for this form type.

documentFormatFiles[]

Each entry corresponds to one document line in the original SGML submission. Per-entry fields:

• sequence — numeric string ("1", "2", ...). The complete-submission .txt wrapper uses a single space (" ") for sequence.
• size — file size in bytes, encoded as a string.
• documentUrl — public www.sec.gov/Archives/edgar/... URL for the file.
• type — EDGAR document type. Common values: "40-17F1" for the primary certificate, "GRAPHIC" for embedded images, and a single space (" ") for the complete-submission .txt wrapper.
• description — short label such as "Complete submission text file" or "GRAPHIC". May be absent on the primary form document.

The manifest enumerates every original-submission file regardless of whether the dataset physically packages it. A typical 40-17F1 manifest lists the primary .htm (type=40-17F1), two or three image_*.jpg graphics (type=GRAPHIC) carrying scanned signatures and accountant letterhead, and the complete-submission .txt (type=" "). Of these, only the primary .htm is shipped in the ZIP; the rest are available via the documentUrl values.

entities[]

Each filing carries one or more EDGAR entity records distinguished by a parenthetical role suffix on the companyName value:

• ... (Filed by) — the entity that transmitted the submission to EDGAR.
• ... (Subject) — the entity to which the filing pertains.

For 40-17F1 filings the filer and the subject are typically the same registered investment company or trust, so the same legal entity appears twice with different role suffixes; distinguishing the two roles requires reading the suffix rather than relying on the CIK, which usually matches across both records.

Per-entity fields:

• companyName — legal name plus the role suffix ((Filed by) or (Subject)).
• cik — numeric Central Index Key string.
• irsNo — IRS employer identification number, often "000000000" when not provided.
• stateOfIncorporation — two-letter state code.
• act — governing act, "40" for the Investment Company Act of 1940. Present on the subject entity only.
• fileNo — SEC file number such as "811-22756". Present on the subject entity only.
• filmNo — EDGAR film number assigned to the submission. Present on the subject entity only.
• type — document type for which this entity is recorded ("40-17F1").

The certificate document — internal structure

The packaged document is a .htm file that begins with EDGAR's standard SGML envelope and then contains the rendered HTML body of the certificate. The leading envelope looks like:

          1
          <DOCUMENT>
        

          2
          <TYPE>40-17F1
        

          3
          <SEQUENCE>1
        

          4
          <FILENAME><filerSlug>_40-17f1.htm
        

          5
          <TEXT>
        

          6
          <HTML>
        

          7
            ... certificate body ...
        

          8
          </HTML>
        

          9
          </TEXT>
        

          10
          </DOCUMENT>
        

Inside the <HTML> body the certificate follows the standardized Form N-17f-1 template. Although filers vary in visual styling, the content proceeds in this order:

• Form heading. The full title is reproduced verbatim: "FORM N-17f-1, Certificate of Accounting of Securities and Similar Investments of a Management Investment Company in the Custody of Members of National Securities Exchanges, Pursuant to Rule 17f-1 [17 CFR 270.17f-1]."
• Item 1 — Identifying information. The Investment Company Act file number (the 811- series number), the name of the fund or series whose securities were examined, and the date the examination was completed.
• Item 2 — State identification table. A multi-row table enumerating each US state and territory, with each cell indicating the basis on which the fund is registered or notice-filed in that jurisdiction (typical values include "By Fund", "By Trust", "By Class", "By Prospectus", and "no permit") together with any state permit number. This table is the bulkiest visual element of the document and the principal source of state-level coverage data.
• Item 3 — Exact registrant name. The exact name of the investment company as specified in its registration statement, repeated for legal precision.
• Item 4 — Management's assertion and signature block. A signed statement by officers of the trust or fund attesting on the registrant's behalf. Signatures are typically rendered as scanned graphics in the original submission, which is why the manifest commonly lists GRAPHIC entries even when the certificate body is otherwise short.
• Report of Independent Public Accountant. The accountant's letter, addressed to the trustees or shareholders of the fund, describing the procedures performed (typically comparison of securities held with custodian records, direct confirmation of holdings, and reconciliation of securities counts against the books and records of the fund, the custodian, and any clearing agent), the period or as-of date covered, and the firm's opinion or findings. The accounting firm's name, location, and signature appear at the foot of this section, often as embedded images.

The certificate is short — a few hundred lines of rendered HTML, with most of the visual mass coming from the Item 2 state table — and content variation between filings concentrates in three places: the date the examination was completed, the period covered by the accountant's procedures, and the filing date.

Included content

For each accession the dataset preserves:

• the structured metadata.json envelope, and
• the primary form document(s) from the SGML submission (the certificate .htm file, with the SGML <DOCUMENT> envelope intact).

If a filing happens to contain more than one non-image document, all such documents are included.

Excluded content

Two categories of original-submission content are deliberately omitted from the ZIP:

• Image files (image_*.jpg, .gif, etc.). Scanned signatures, accountant-firm letterhead graphics, and similar embedded raster images are listed in documentFormatFiles[] with type="GRAPHIC" but are not physically packaged. The substantive disclosure of a 40-17F1 filing is text-bearing, the images are rendering artifacts of the printed-and-scanned signature workflow, and including them would inflate container size with non-textual material that adds little to machine extraction. Where a consumer needs the original signature image, it is retrievable directly from documentFormatFiles[].documentUrl.
• The complete-submission SGML wrapper (<accessionNo>.txt). The full concatenated SGML artifact that EDGAR generates for the submission is referenced by URL in linkToTxt and listed in documentFormatFiles[] with a single-space type, but it is not packaged inside the record folder. Its substantive content is already represented by the per-document files that are included; bundling both would duplicate the certificate body verbatim.

Both classes of excluded content remain reachable via the URLs in documentFormatFiles[] and linkToTxt.

Format conventions over time

40-17F1 submissions were originally transmitted as plain ASCII/SGML text in the late 1990s and early 2000s, with the certificate body inlined directly within the <TEXT> block of the EDGAR SGML envelope. As EDGAR transitioned to HTML primary documents, the .htm file became the standard carrier for the certificate, with the SGML <DOCUMENT> header retained as the outer wrapper. The dataset preserves whatever document type the filer transmitted, so older records may carry plain-text primary documents while modern records carry HTML. The file-types found in the dataset are TXT, JSON, and HTML, with JSON corresponding to the per-record metadata envelope and HTML being the dominant primary-document encoding for filings made in recent years.

The required content of Form N-17f-1 has itself been remarkably stable across the EDGAR era: identification of the investment company, identification of the custodian exchange member, the period and scope of the examination, and the independent accountant's certification have all been required throughout. Amendments captured under 40-17F1/A may revise any of these elements — most commonly to correct identifying information or to substitute a corrected accountant's report — but are otherwise structurally indistinguishable from a primary 40-17F1 record.

Interpretation and extraction notes

• Skip the SGML envelope before HTML parsing. The leading <DOCUMENT>, <TYPE>, <SEQUENCE>, <FILENAME>, and <TEXT> tags precede the inner <HTML> body. Lenient HTML parsers tolerate them as unknown elements, but cleaner extraction strips everything before <HTML> (or the first body-level tag) and stops at </HTML> before the trailing </TEXT></DOCUMENT>.
• Use the role suffix, not the CIK, to separate filer from subject. Filer and subject CIKs are usually identical for this form type; the (Filed by) and (Subject) parentheticals on companyName are the reliable discriminator, and several entity-only fields (act, fileNo, filmNo) populate only on the subject record.
• Auditing-firm identity may be image-bound. Because signatures and accountant letterhead are typically rendered as graphics, the textual body of the certificate may not contain a typed firm name beneath the accountant's report. Reliable identification of the audit firm therefore requires either OCR of the omitted images (retrievable from documentFormatFiles[] URLs) or text-parsing the firm name as written in the addressee or signature line of the report letter, where it is usually spelled out in plain text.
• Item 2 is the structured-extraction target. The state-by-state registration table is the single most data-rich element of the document. Its row labels follow the standard alphabetical list of US states and territories, and its cell values draw from a small recurring vocabulary, making it amenable to deterministic table extraction.
• No XBRL. 40-17F1 filings are not XBRL-tagged, so linkToXbrl is always empty and dataFiles[] is always an empty array. Series/class metadata is likewise not collected for this form, leaving seriesAndClassesContractsInformation[] empty across the dataset.
• Amendments do not carry an explanation item. 40-17F1/A filings have no separate "amendment explanation" item by form design; the reasons for amendment are typically stated in a brief cover note inside the certificate body, or implied by comparison with the prior certificate identified by accession number.

Who Files or Publishes This Dataset, and When

Who files the record

The EDGAR filer is the registered management investment company — typically an open-end fund (mutual fund) or closed-end fund registered under the Investment Company Act of 1940. The fund signs and submits the form, but the substantive document inside is a certificate prepared and signed by an independent public accountant retained by the fund. The custodian — a broker-dealer that is a member of a national securities exchange — is the entity being examined; it is named in the filing but is not the filer and not the certifier.

Three roles, kept distinct:

• Filer: the registered management investment company (mutual or closed-end fund).
• Certifier: the independent public accountant performing the verification.
• Custodian (subject of examination): an exchange-member broker-dealer holding the fund's securities.

Filing population

Form 40-17F1 is used only by registered management investment companies that have elected to place portfolio securities and similar investments with an exchange-member custodian under Section 17(f) of the 1940 Act and Rule 17f-1. Funds using a qualifying bank custodian under Section 17(f)(1) do not file this form. Unit investment trusts and face-amount certificate companies are outside the rule's scope. The relevant population is therefore narrower than the universe of registered investment companies overall.

Triggering event

The filing is examination-driven, not calendar-driven. Rule 17f-1(b)(4) under the 1940 Act conditions a fund's use of an exchange-member custodian on the fund retaining an independent public accountant who must:

• verify the custodied securities by actual examination at least three times per fiscal year, and
• conduct at least two of those examinations without prior notice to the custodian.

Each examination produces a written certificate describing the nature and extent of the verification. That certificate must be transmitted to the Commission promptly after the examination. Form 40-17F1 is the EDGAR vehicle for that transmittal. There is no fixed quarterly or annual deadline analogous to a 10-K; timing is set by when the accountant performs each examination, with at least two of the three dates unknown to the custodian in advance.

In aggregate, each subject fund generates roughly three filings per fiscal year, with irregular spacing inside the year.

Form 40-17F1/A amendments

A 40-17F1/A record is an amendment to a previously filed certificate, not a new examination. Amendments are used to correct, supplement, or replace an earlier submission — for example, fixing metadata, correcting the description of securities verified, or substituting a defective certificate document. The trigger is the need to revise a prior filing, not a fresh verification event.

Important distinctions

• Bank custody (Section 17(f)(1)): funds using a qualifying bank custodian do not produce 40-17F1 records; the verification-and-certificate regime of Rule 17f-1 only applies to exchange-member custody.
• Self-custody (Rule 17f-2): a fund that maintains custody of its own securities files certificates under Rule 17f-2 on Form N-17f-2 (EDGAR code 40-17F2). That is a separate, parallel regime and is not part of this dataset.
• Fund vs. accountant vs. custodian: the EDGAR filer is the fund; the evidentiary signature is the independent public accountant's; the custodian is the examined party. Confusing these three is the most common analytical error with this form.
• Series registrants: many filings come from registrants with multiple series. The filer of record is the registrant, and a single certificate may cover one or more series held under the same custody arrangement.

How This Dataset Differs From Similar Datasets or Filings

Form 40-17F1 sits in a tight cluster of Investment Company Act custody and audit filings. The closest analog is its self-custody twin (40-17F2); other nearby filings (N-CEN, N-CSR/N-CSRS, N-PORT/N-Q, ADV-E, N-CR) touch the same regulatory neighborhood but answer different questions.

Closest related filings

Form 40-17F2 (Form N-17f-2) — self-custody accountant certificate. Direct sibling: same document shape (independent accountant's certificate, fiscal period, securities examined), but filed under Rule 17f-2 for funds holding their own securities, whereas 40-17F1 is filed under Rule 17f-1 when securities are held by a member of a national securities exchange. Boundary: If the custodian is an exchange-member, it is 40-17F1; if the fund self-custodies, it is 40-17F2.

Form N-CEN — annual fund census. Structured XML annual report identifying custodians and custody type, but containing no certificate text, methodology, or examination results. Boundary: Use N-CEN to discover which funds use exchange-member custody; use 40-17F1 to read the actual verification certificates.

Form N-CSR / Form N-CSRS — certified shareholder reports. Annual and semi-annual shareholder reports covering audited or unaudited financial statements and SOX certifications; the accountant audits the fund's financial statements, not the custodian's holdings. Boundary: N-CSR audits NAV, valuations, and expenses; 40-17F1 verifies the existence of securities at an exchange-member custodian.

Form N-PORT / legacy Form N-Q — portfolio holdings reports. Monthly (N-PORT) and historically quarterly (N-Q) disclosures of fund positions, valuations, derivatives, and liquidity tags. Boundary: N-PORT/N-Q answer "what does the fund own?"; 40-17F1 answers "did an independent accountant confirm those securities exist at the custodian?"

Form ADV-E — investment adviser surprise examination certificate. Advisers Act Rule 206(4)-2 filing transmitting an accountant's surprise-exam certificate over client assets held by an adviser with custody; same audit logic, different statute and filer. Boundary: ADV-E covers adviser custody of client assets under the Advisers Act Rule 206(4)-2; 40-17F1 covers registered investment companies whose securities sit with an exchange-member custodian under the Investment Company Act.

Form N-CR — current report by a registered investment company. Event-driven money-market-fund disclosures (portfolio support, liquidity fees, gating, credit events); shares filer population but no custody-verification content. Boundary: N-CR is triggered by material events; 40-17F1 is a recurring custody-audit certificate.

What makes 40-17F1 distinct

Three properties together appear in no neighboring dataset: (1) it carries the actual independent-accountant certificate text rather than metadata pointing to it; (2) it is tied specifically to exchange-member custody under Rule 17f-1, not self-custody, bank custody, or adviser custody; and (3) it follows a verification cadence of at least three examinations per fiscal year, distinct from annual financial reporting, monthly portfolio reporting, or event-driven disclosure. For research on custody controls, audit cadence, accountant identity, or examination methodology under the Rule 17f-1 regime, 40-17F1 is the primary source; every other form above answers a related but separate question.

Who Uses This Dataset

Form 40-17F1 certificates are short but name a precise set of parties: the registered management investment company, the exchange-member custodian, the independent public accountant, the fiscal period, and the examination dates. The user base is narrow and field-specific.

Fund compliance officers and CCOs

Compliance officers at registered management investment companies use the dataset to confirm that the required three independent verifications were filed each fiscal year, reconstruct examination cadence across years, and prepare for SEC exams. They rely on the fiscal period, examination dates, custodian name, auditor identity, signature block, and the amendment history (40-17F1/A) to spot prior errors and document remediation to the board.

Investment-management lawyers

In-house and outside counsel mine the dataset as a precedent library when drafting Rule 17f-1 certificates and responding to SEC staff comments. The accountant's procedural language, verification wording, and treatment of book-entry securities are the load-bearing fields. Enforcement and litigation counsel use historical custodian and auditor entries to reconstruct custody arrangements during a disputed period.

Fund auditors performing Rule 17f-1 examinations

PCAOB-registered audit firms benchmark their own certificate templates against peer wording on examination scope and procedures. Methodology and quality teams pull the accountant signature, firm name, and procedure description for internal peer review and engagement-partner training.

SEC examination and Division of Investment Management staff

Examiners use the structured population to flag late filings, gaps in the three-times-per-fiscal-year cadence, undisclosed custodian or auditor changes, and amendments that materially restate prior certificates. Fiscal period, examination dates, and amendment lineage drive risk-based exam targeting and sweep reviews. The Division of Investment Management supervises the registered-fund population from which these filings originate.

Custodian operations teams at exchange-member broker-dealers

Custody operations and control teams reconcile the custodian-name field across all filings to identify every fund for which their firm is named, then match that population to internal customer master records for KYC, onboarding, and client-service review.

Fund administrators

Third-party administrators and outsourced compliance providers track filing completeness for client funds using filing date, fiscal period, accession number, and amendment history, and surface compliance dashboards for fund boards.

Fund-relationship-graph data engineers

Quant and data-engineering teams extract the investment-company, custodian, and auditor names per certificate to build fund-to-custodian-to-auditor graphs that complement N-CEN, N-1A, and N-PORT. Outputs feed custody and auditor concentration analysis, counterparty mapping, and operational-risk model features.

Academic researchers

Researchers in fund governance, audit specialization, and custody concentration use the longitudinal panel (1998 to present) to study persistence of custodian and auditor relationships, amendment frequency by fund family, and the evolution of custody verification practice. The consistent metadata supports fund-fiscal-year panel datasets.

Investigative journalists and fraud researchers

Forensic reporters flag unexplained auditor or custodian changes, missed examination cadence, and sudden amendments preceding enforcement or fund failure. The amendment trail and the custodian-auditor-fund triple are the primary signals.

Synthesis

The dataset's value lies in a small, structured set of named parties and a long, consistent historical panel. Fund-side compliance and legal teams use it for self-audit and precedent; auditors benchmark certificate language; custodians and administrators reconcile their named roles; regulators surveil cadence and amendments; and quant, academic, and investigative users mine the fund-custodian-auditor graph for relationships and anomalies.

Specific Use Cases

The dataset supports a narrow set of operational workflows built around the named parties (fund, custodian, accountant), the examination cadence, and the amendment trail.

• Verifying Rule 17f-1 examination cadence for a fund family (compliance officers and CCOs). Pull every accession for a given subject CIK, sort by effectivenessDate and the Item 1 examination-completion date, and confirm at least three independent verifications per fiscal year. Gaps, late filings, and 40-17F1/A amendments feed a board-ready remediation memo and an SEC-exam binder.

• Building a fund-to-custodian-to-auditor relationship graph (data engineers and quant teams). For each record, extract the registrant name from Item 3, the exchange-member custodian named in the certificate body, and the accountant firm from the addressee or signature line of the Report of Independent Public Accountant. Joined with entities[].cik and fileNo, the triple becomes a longitudinal edge list that complements N-CEN custodian fields and supports auditor- and custody-concentration metrics.

• Drafting and benchmarking certificate language (investment-management lawyers and PCAOB audit firms). Treat the corpus as a precedent library: extract the accountant's procedure description (comparison with custodian records, direct confirmation, reconciliation against books and records) and the management assertion in Item 4. Methodology teams diff peer wording on book-entry treatment and examination scope when revising in-house certificate templates or responding to SEC staff comments.

• Targeting risk-based examinations and sweeps (SEC examination staff). Use formType to isolate 40-17F1/A amendments, then chain each amendment to its prior accession by subject CIK and fiscal period to flag material restatements, undisclosed custodian or auditor swaps, and broken three-per-year cadence. The amendment lineage and the Item 1 examination dates drive the targeting list.

• Reconciling named-custodian populations (custodian operations at exchange-member broker-dealers). Scan certificate bodies for the custodian-name string corresponding to the firm, collect every subject-entity CIK and fileNo where the firm is named, and reconcile that list against internal customer master records to surface unbooked relationships and KYC or onboarding gaps.

• Detecting auditor or custodian changes preceding fund stress (investigative journalists and forensic researchers). Track changes across consecutive filings in the accountant firm name (parsed from the report letter) and the custodian named in the certificate body for the same subject CIK. Combine with the 40-17F1/A amendment trail and filedAt timestamps to flag mid-cycle auditor swaps or sudden restatements that precede enforcement or fund liquidation.

• Constructing a state-registration panel from Item 2 (academic researchers and fund administrators). Deterministically extract the Item 2 state-by-state table, mapping each row's state code to its registration basis ("By Fund", "By Trust", "By Class", "By Prospectus", "no permit") and any permit number. The result is a fund-fiscal-year panel of state-level coverage usable for studies of distribution scope and notice-filing patterns.

Dataset Access

Dataset Index JSON API: https://api.sec-api.io/datasets/form-4017f1-files.json

This endpoint returns the dataset's metadata, including its name, description, last updated timestamp, earliest sample date, total record count, total archive size, covered form types (40-17F1 and 40-17F1/A), container format, and file types contained within. It also returns the download URL for the full dataset archive and a list of monthly container files, each with its size, record count, last updated timestamp, and download URL. Polling this endpoint allows you to detect which monthly containers have changed in the most recent refresh run and selectively download only the updated containers. This endpoint does not require an API key.

Example response:

          1
          {
        

          2
            "datasetId": "1f13365b-9ae0-69a5-b823-7b7ab2a62a3b",
        

          3
            "datasetDownloadUrl": "https://api.sec-api.io/datasets/form-4017f1-files.zip",
        

          4
            "name": "Form 40-17F1 Files Dataset",
        

          5
            "updatedAt": "2026-04-15T12:06:27.506Z",
        

          6
            "earliestSampleDate": "1998-02-01",
        

          7
            "totalRecords": 915,
        

          8
            "totalSize": 5660601,
        

          9
            "formTypes": ["40-17F1", "40-17F1/A"],
        

          10
            "containerFormat": "ZIP",
        

          11
            "fileTypes": ["TXT", "JSON", "HTML"],
        

          12
            "containers": [
        

          13
              {
        

          14
                "downloadUrl": "https://api.sec-api.io/datasets/form-4017f1-files/2026/2026-03.zip",
        

          15
                "key": "2026/2026-03.zip",
        

          16
                "size": 138291,
        

          17
                "records": 7,
        

          18
                "updatedAt": "2026-04-15T12:06:27.506Z"
        

          19
              }
        

          20
            ]
        

          21
          }
        

Download Entire Dataset: https://api.sec-api.io/datasets/form-4017f1-files.zip?token=YOUR_API_KEY

Use this URL to download the full dataset as a single ZIP archive containing every monthly container from February 1998 to the present. This endpoint requires an API key.

Download Single Container: https://api.sec-api.io/datasets/form-4017f1-files/2026/2026-03.zip?token=YOUR_API_KEY

Each monthly container is a ZIP archive named YYYY-MM.zip and grouped under its year directory. Use the downloadUrl field of any entry in the index's containers array to fetch a single month rather than the full dataset. This endpoint requires an API key.

Inside each container, every filing is stored under its accession number, for example 0001145443-08-000123/metadata.json alongside the original EDGAR submission documents (HTML, TXT) for that filing, excluding images.

Frequently Asked Questions

What form does this dataset cover?

The dataset covers EDGAR submissions of form type 40-17F1 and its amendment 40-17F1/A. The same filing is known by its legal title Form N-17f-1, the "Certificate of Accounting of Securities and Similar Investments of a Management Investment Company in the Custody of Members of National Securities Exchanges, Pursuant to Rule 17f-1 [17 CFR 270.17f-1]." Both labels are aliases for the same instrument.

What does one record in this dataset represent?

One record is a single EDGAR 40-17F1 or 40-17F1/A submission, identified by its SEC accession number and packaged as a per-accession folder containing a metadata.json envelope and the certificate document. Each record captures one custody-verification event: an independent public accountant's certificate of examination of securities held by a registered management investment company at an exchange-member custodian.

Who is required to file this form?

Registered management investment companies — typically open-end (mutual) and closed-end funds — that place portfolio securities with a custodian who is a member of a national securities exchange under Section 17(f) of the Investment Company Act of 1940 and Rule 17f-1. Funds using a qualifying bank custodian or self-custodying their securities are outside the scope; unit investment trusts and face-amount certificate companies are also excluded.

How often are records added?

Filing is examination-driven, not calendar-driven. Rule 17f-1(b)(4) requires at least three independent examinations per fiscal year — with at least two performed without prior notice to the custodian — so each subject fund typically generates roughly three filings per fiscal year, irregularly spaced. Containers are refreshed monthly.

What time period does the dataset cover?

The dataset's earliest sample date is February 1, 1998, and it extends to the present, with new monthly containers added as filings are accepted by EDGAR. Older records were transmitted as plain ASCII/SGML text and modern records are HTML, both wrapped in the EDGAR SGML <DOCUMENT> envelope.

What file format is the dataset distributed in?

The dataset is distributed as monthly ZIP archives named YYYY-MM.zip, organized under per-year directories. Inside each container, every filing lives under a per-accession folder containing a metadata.json plus the certificate document(s). The file types found in the dataset are TXT, JSON, and HTML; image files and the complete-submission SGML wrapper are referenced by URL in documentFormatFiles[] but are not physically packaged.

How does this dataset differ from Form 40-17F2?

Form 40-17F2 (Form N-17f-2) is the direct sibling: same document shape, but filed under Rule 17f-2 by funds that hold their own securities (self-custody), whereas Form 40-17F1 is filed under Rule 17f-1 when securities are held by a member of a national securities exchange. If the custodian is an exchange-member, the filing is 40-17F1; if the fund self-custodies, it is 40-17F2.