The Form 40-17GCS Files Dataset collects every Form 40-17GCS notice filed to EDGAR from January 2016 to the present. Form 40-17GCS is the event-driven filing that registered management investment companies use to notify the SEC of a claim made or a settlement reached under their fidelity bond, as required by Rule 17g-1(g)(2) and Rule 17g-1(g)(3) under the Investment Company Act of 1940. Each record in the dataset corresponds to one accession-numbered submission and packages the EDGAR submission header, the primary notice document (HTML or PDF), and the combined submission text file produced by EDGAR. Because a single fidelity bond is commonly shared by an entire fund complex under a Joint Insured Bond, one submission frequently covers multiple registrants under a single accession number. The dataset is distributed as monthly ZIP containers and contains HTML, JSON, and PDF file types.
Programmatically retrieve the full list of dataset archive files, download URLs and dataset metadata.
Dataset Index JSON API
Download the entire dataset as a single archive file.
Download Entire Dataset:
Download a single container file (e.g. monthly archive) from the dataset.
Download Single Container:
The dataset contains every Form 40-17GCS submission accepted by EDGAR from January 2016 to the present. Form 40-17GCS is the EDGAR form used to satisfy the notification duties imposed on registered management investment companies by Rule 17g-1(g)(2) and Rule 17g-1(g)(3) under the Investment Company Act of 1940. Rule 17g-1 requires a fund to maintain a fidelity bond covering larceny and embezzlement by its officers and employees; paragraph (g)(2) requires prompt notice to the Commission when a claim is made under that bond, and paragraph (g)(3) requires a follow-on notice when the terms of any settlement are agreed. Both notifications must reach EDGAR within five days of the triggering event, which is why 40-17GCS filings are short, narrowly scoped, and predominantly narrative rather than structured financial disclosures. The form is filed in the Investment Company Act ("40") series under the EDGAR form code 40-17GCS.
Because a single fidelity bond is commonly held jointly by an entire fund complex under an Investment Company Blanket Bond or Joint Insured Bond, one 40-17GCS submission routinely covers multiple registrants at once. In that case the EDGAR header lists every covered fund as a separate filer under a single shared accession number. The dataset is delivered as ZIP containers partitioned by month under a YYYY/YYYY-MM.zip scheme, and the file types found inside are HTML, JSON, and PDF. No re-rendering or content transformation is applied: each record is a faithful copy of the EDGAR submission minus image attachments.
One record in this dataset corresponds to a single Form 40-17GCS submission on EDGAR, identified by its 18-digit accession number. Physically, a record is an accession-number-named folder containing a metadata.json header file (derived from the EDGAR submission index) and the source documents that make up the original filing, minus any image attachments. Each folder maps one-to-one onto a single notice of claim or notice of settlement under a fidelity bond maintained by one or more registered management investment companies.
Accession folders use the 18-digit form with dashes removed: filing 0000088053-25-000065 becomes 000008805325000065/. The canonical dashed accession number is preserved inside metadata.json as accessionNo, and every EDGAR URL in the linkTo* fields uses that dashed form. Monthly ZIP containers follow a YYYY/YYYY-MM.zip partition scheme.
A record has two layers. The outer layer is metadata.json, the normalized EDGAR submission header that also indexes the underlying document files. The inner layer is the set of filing documents referenced by that metadata: the primary 40-17GCS notice and, in most accessions, the combined submission text file that EDGAR produces as the consolidated SGML representation of the full submission.
In order, an accession folder typically contains:
metadata.json — the normalized EDGAR header and document index..htm, occasionally a PDF..txt), excluding images.metadata.json headermetadata.json captures the submission-level facts needed to interpret the filing and cross-reference it against EDGAR. The fields that carry intentional meaning are:
formType — always 40-17GCS in this dataset.accessionNo — dashed canonical EDGAR accession number.filedAt and effectivenessDate — EDGAR acceptance timestamp and effectiveness date.description — the short description line from the EDGAR submission header (commonly "Form 40-17GCS -" or similar).linkToFilingDetails — URL to the primary HTML document on sec.gov.linkToTxt — URL to the combined submission SGML text file.linkToHtml — URL to the EDGAR filing index page for the accession.linkToXbrl — present but empty; 40-17GCS is not an XBRL form.documentFormatFiles — array with one object per submitted document, each carrying sequence, size, documentUrl, description, and type. For a typical 40-17GCS the entries are the primary .htm (type: "40-17GCS", with a free-text description such as "MULTIPLE REGISTRANTS CLAIM" or an issuer-specific equivalent) and the combined submission text file.dataFiles — array for auxiliary data files; empty for this form type.seriesAndClassesContractsInformation — container for EDGAR series-and-class data; typically empty for 40-17GCS because the notice addresses the fund at the registrant level rather than the series or class level.entities — the most distinctive block on this form: one entry per EDGAR filer on the submission. Each entity object carries companyName, cik, fileNo, irsNo, filmNo, fiscalYearEnd, stateOfIncorporation, act (always "40"), and type (40-17GCS). Because fidelity bonds are commonly shared across an entire family of funds, this array is frequently multi-valued and is the authoritative machine-readable list of registrants to which the notice pertains.id — an internal 32-character hex identifier.The primary document is delivered in EDGAR's SGML document wrapper with an inner HTML payload. The wrapper declares the document type, sequence number, filename, and description, and the <TEXT> section carries the HTML body:
1
<DOCUMENT>
2
<TYPE>40-17GCS
3
<SEQUENCE>1
4
<FILENAME>r4017gcs_012425.htm
5
<DESCRIPTION>MULTIPLE REGISTRANTS CLAIM
6
<TEXT>
7
<HTML>... body of the claim or settlement notice ...</HTML>
8
</TEXT>
9
</DOCUMENT>
The HTML body is short and prose-oriented. There is no SEC-mandated template, but a 40-17GCS notice ordinarily contains these informational components:
The narrative is not machine-tagged: the loss amount, bond identifier, insurer name, and counterparties appear as free text, so extraction is text-based.
Each record includes the full EDGAR-derived metadata header, the primary 40-17GCS notice as filed (HTML or PDF), and any additional textual submission artifacts that accompanied it — most commonly the combined submission SGML text file that EDGAR produces as a consolidated representation of the entire accession. The file types found in the dataset are HTML, JSON, and PDF. Original EDGAR filenames are preserved unchanged inside the accession folder so that they match the URLs recorded in metadata.json.
Image attachments that were part of the original EDGAR submission are intentionally omitted. This affects filings in which the notice was submitted as a scanned document with embedded signature images or logos; the textual body is still available, but raster attachments are not reproduced. Beyond the image exclusion, the record is a faithful copy of the submission with no re-rendering or content transformation.
A structural feature worth highlighting is that 40-17GCS filings frequently cover multiple registrants under a single accession number because one blanket fidelity bond is shared across an entire family of funds. In the metadata this surfaces as a long entities array, with each fund appearing as its own filer object complete with CIK, file number, IRS number, fiscal year end, and state of incorporation. Inside the narrative body the same fact is expressed in language such as "on behalf of the following registrants" followed by a list of fund names. When the underlying loss is traceable to only a subset of the covered funds, that subset is normally named explicitly in the body even though all co-insured registrants appear in the header-level entities array. Consumers extracting events from this dataset should therefore treat entities as the universe of bond co-insureds and rely on the narrative body as the authoritative source for which funds actually suffered the loss.
Although both variants share the same form code, the two subparagraphs of Rule 17g-1(g) produce materially different content. A (g)(2) notice is forward-looking: filed shortly after a claim is made, it typically records an estimated loss, identifies the insurer and the bond, and describes the underlying event while investigation is still in progress. A (g)(3) notice is backward-looking: it records the terms of settlement, including the amount paid, the allocation of recovery among covered funds, and the resolution date. A single underlying incident can therefore generate two separate records in the dataset — first a (g)(2) claim notice and later a (g)(3) settlement notice, each with its own accession number. Nothing in the file layout distinguishes the two variants; the distinction must be inferred from the rule citation and the tense of the narrative.
metadata.json as accessionNo, and all EDGAR cross-references in the linkTo* fields use the dashed form.entities array is the structured list of all filing parties. The narrative body is the source of truth for which of those entities actually suffered loss.type and filename fields in documentFormatFiles rather than assuming HTML.Each record is a single Form 40-17GCS filing submitted to EDGAR by a registered management investment company that maintains a fidelity bond under Section 17(g) of the Investment Company Act of 1940. The filing is a regulatory notice about a claim or settlement under that bond, not a periodic disclosure.
The filer population is limited to registered management investment companies, including:
The registrant named on EDGAR is the fund entity that is the insured under the bond. Where a fund complex uses a joint insured bond under Rule 17g-1(b), the affected covered fund is the filer.
Entities outside this filing path:
Form 40-17GCS is event-driven, not periodic. It is triggered by one of two events tied to the fund's fidelity bond:
The obligation only arises when a covered loss event (for example, employee theft, forgery, or computer fraud at the fund or a service provider) produces a claim or settlement. There is no materiality threshold: any claim or settlement, regardless of dollar size, triggers the notice. Most registered funds file nothing in a given year because no covered event has occurred, which is why the dataset is small in volume.
The fund must file the notice with the Commission within five days of:
A single covered loss can therefore generate two filings by the same fund: one at claim, one at settlement. Amendments (40-17GCS/A) update previously reported information about the same claim or settlement rather than starting a new trigger. Rule 17g-1 separately requires the fund to notify its board of directors, but that notice is a recordkeeping matter and is not filed on EDGAR.
Form 40-17GCS sits inside a narrow cluster of Investment Company Act filings that govern fidelity bond coverage for registered management investment companies. The most useful comparisons are the other Rule 17g-1 filing (Form 40-17G), the annual census report (Form N-CEN), and the custody-safeguard filings under Section 17 (Form N-17f-1 and Form N-17f-2). Each overlaps with 40-17GCS on subject matter or filer population but diverges sharply on trigger, timing, or content.
Form 40-17G is the nearest neighbor and the most frequent source of confusion. Both forms are filed under Rule 17g-1 and both concern the same fidelity bond, but they capture different moments in its lifecycle.
In short, 40-17G shows what coverage exists; 40-17GCS shows when that coverage has been tested. The datasets are complementary, not substitutable.
Form N-CEN is the annual structured census report filed by registered investment companies (successor to N-SAR). It covers directors, service providers, securities lending, fund-of-funds status, and fidelity bond metadata, among many other items.
For time-sensitive monitoring of fidelity bond events, N-CEN is a lagging, low-resolution substitute.
These accountant certifications under Rules 17f-1 and 17f-2 address safekeeping of fund assets by self-custodians or certain custodial arrangements. They share the Section 17 operational-safeguard family with 40-17GCS but do not overlap in content.
A loss covered by the fidelity bond flows to 40-17GCS, not to a custody certificate, even if the underlying incident also raises custody concerns.
Form N-CSR transmits fund financial statements semi-annually. A fidelity bond loss large enough to be material may eventually surface in N-CSR commentary or financials.
N-CSR is a downstream, summarized view of losses significant enough to reach financial statements; it is not a substitute for tracking claim-level events.
| Dimension | 40-17GCS | 40-17G | N-CEN | N-17f-1/2 | N-CSR |
|---|---|---|---|---|---|
| Trigger | Claim or settlement | Bond execution/renewal | Annual cycle | Custody arrangement | Semi-annual cycle |
| Timing | 5 business days | Periodic | Annual | Periodic | Semi-annual |
| Content | Narrative loss notice | Bond document and approvals | Structured census data | Accountant attestation | Audited financials |
| Scope | Single claim event | Coverage terms | Fund operations broadly | Custody controls | Fund financial results |
Form 40-17GCS is the only SEC filing stream that captures fidelity bond claim and settlement events at the granularity of the individual loss and within days of occurrence. Form 40-17G documents the bond itself but not claim activity. N-CEN provides annual structured bond metadata without claim narratives. Custody-related 17f filings cover adjacent safeguarding questions but not insurance. N-CSR reflects only those losses material enough to appear in financial statements, and only on a periodic lag. For anyone studying operational loss experience, insurer exposure, or Rule 17g-1 compliance activity in the registered fund industry, 40-17GCS is narrow and non-substitutable.
The Form 40-17GCS Files Dataset is consulted by a narrow set of professionals focused on fund operations, insurance coverage, and regulatory compliance. Although the overall record count is small, the dataset is one of the only public windows into realized fidelity bond claims at registered funds, and each profession draws on a different slice of the same core fields: claim narrative, loss amount, insurer, and settlement terms.
Compliance staff at registered funds benchmark their own 40-17GCS reporting against peers. They focus on claim descriptions, filing timing relative to the five-day window, and how losses are characterized. Used for drafting notices, training on Rule 17g-1, and calibrating disclosure detail.
Underwriters writing investment company bonds mine the dataset for loss frequency and severity. Key fields: insurer identity, loss amount, circumstances, and settlement outcome. Feeds pricing models, policy form revisions, and underwriting guidelines on employee dishonesty.
Brokers advising fund complexes use realized loss amounts and event types to support coverage-adequacy conversations with boards and treasurers at annual renewal. They cite peer settlements to justify limits, deductibles, and policy provisions.
Independent directors approve bond amount, form, and coverage under Rule 17g-1. Their counsel reviews peer loss amounts and event types to inform board resolutions, annual approvals, and minutes.
Outside and in-house counsel serving fund complexes review precedent language for 40-17GCS notices, advising on narrative framing, party identification, and settlement wording. Also used to coordinate with related disclosures on Form N-CEN and state insurance reporting.
Engaged after suspected employee dishonesty, embezzlement, or misappropriation. They reference the dataset for comparable loss descriptions, detection methods, and settlement-versus-claim ratios to scope investigations and recommend control remediation.
Risk teams at fund advisers, transfer agents, and administrators populate internal loss databases and calibrate scenarios. Focus: event type (theft, forgery, computer fraud), loss magnitude, and counterparty patterns. Feeds risk-and-control self-assessments and vendor due diligence.
Examination and rulemaking staff track filing timeliness, completeness, and emerging loss patterns across the industry to set exam priorities and review whether Rule 17g-1 reporting functions as intended.
Short, structurally consistent, event-driven filings make 40-17GCS useful for training extraction pipelines on insurer names, claim amounts, loss types, and settlement terms, and for grounding retrieval-augmented answers on fund fidelity bond experience.
Academic and industry researchers treat the dataset as one of the few public sources of realized fidelity bond loss experience for U.S. registered funds, analyzing frequency, severity distributions, and recurring event types for working papers and external loss databases.
Form 40-17GCS filings are small in number but uniquely specific: each record ties a named fidelity bond, a named insurer, a loss amount, and a set of registered fund co-insureds to a single claim or settlement event. The following workflows use that content directly.
Building a realized fidelity bond loss table for ICI bond underwriting. Parse the narrative body of each primary 40-17GCS document to extract insurer name, bond type (ICI Blanket Bond or Joint Insured Bond), approximate loss amount, event type (embezzlement, forgery, social engineering, shareholder account fraud), and settlement amount where a (g)(3) notice exists. The resulting table feeds frequency-severity models used to price new and renewing investment company bonds.
Pairing (g)(2) claim notices with their later (g)(3) settlements. Within the dataset, link each claim notice to its corresponding settlement notice using shared registrants in the entities array, the named insurer, the bond identifier, and narrative cross-references. The paired set supports claim-to-settlement ratio analysis, recovery-rate estimates, and time-to-settlement metrics for broker coverage-adequacy discussions with fund boards.
Monitoring filing-timeliness against the five-day rule. Compare filedAt in metadata.json against the event date stated in the narrative body to flag filings that appear to exceed the Rule 17g-1(g)(2) or (g)(3) five-day window. Examination staff and compliance teams use this as input to exam prioritization and to internal self-assessment of notice workflows.
Mapping fund-family co-insurance relationships. Treat the entities array as a machine-readable list of bond co-insureds on each filing and aggregate across the dataset to reconstruct which fund complexes share a single blanket bond. The resulting registrant-to-bond mapping supports board counsel reviewing annual 17g-1 approvals and brokers confirming named-insured schedules at renewal.
Training extraction and RAG pipelines on fidelity-bond narratives. Use the short, consistent prose bodies to train or evaluate extractors that pull insurer name, policy identifier, loss amount, loss type, affected series, and settlement terms from unstructured notice text. The same corpus grounds retrieval-augmented answers to questions about precedent claim language, disclosure framing, and typical settlement wording.
Scoping forensic investigations by comparable-event lookup. When engaged on a suspected employee-dishonesty or social-engineering loss at a fund complex, query the dataset by event type and approximate loss magnitude to retrieve comparable filings. The narrative sections describing detection method, counterparty role, and remediation provide reference points for investigation scope and control-gap reporting.
The Form 40-17GCS Files dataset can be accessed through a JSON index endpoint for metadata discovery, a full archive download, or direct download of individual container files.
Dataset Index JSON API: https://api.sec-api.io/datasets/form-4017gcs-files.json
Returns dataset-level metadata (name, description, last updated timestamp, earliest sample date, total records, total size, form types, container format, and file types), the full dataset download URL, and the list of all container files with per-container size, record counts, updated timestamps, and download URLs. This endpoint does not require an API key and can be polled to detect which containers were updated in the most recent refresh run, so downstream systems can selectively download only the changed containers on a day-by-day basis.
Example response:
1
{
2
"datasetId": "1f13365b-9ae0-6a4c-a256-7d952bd1b629",
3
"datasetDownloadUrl": "https://api.sec-api.io/datasets/form-4017gcs-files.zip",
4
"name": "Form 40-17GCS Files Dataset",
5
"updatedAt": "2026-04-16T08:43:31.652Z",
6
"earliestSampleDate": "2016-01-01",
7
"totalRecords": 22,
8
"totalSize": 165144,
9
"formTypes": ["40-17GCS"],
10
"containerFormat": "ZIP",
11
"fileTypes": ["HTML", "JSON", "PDF"],
12
"containers": [
13
{
14
"downloadUrl": "https://api.sec-api.io/datasets/form-4017gcs-files/2026/2026-03.zip",
15
"key": "2026/2026-03.zip",
16
"size": 13818,
17
"records": 2,
18
"updatedAt": "2026-04-16T08:43:31.652Z"
19
}
20
]
21
}
Download Entire Dataset: https://api.sec-api.io/datasets/form-4017gcs-files.zip?token=YOUR_API_KEY
Downloads the complete dataset as a single ZIP archive covering all Form 40-17GCS filings from January 2016 to the present. This endpoint requires an API key.
Download Single Container: https://api.sec-api.io/datasets/form-4017gcs-files/2026/2026-03.zip?token=YOUR_API_KEY
Downloads one individual monthly container file instead of the full dataset, which is useful for incremental updates. This endpoint requires an API key.
The dataset covers every Form 40-17GCS notice filed on EDGAR. Form 40-17GCS is the event-driven notice that registered management investment companies use to report a claim made or a settlement reached under their fidelity bond, as required by Rule 17g-1(g)(2) and Rule 17g-1(g)(3) under the Investment Company Act of 1940.
One record is a single Form 40-17GCS submission on EDGAR, identified by its 18-digit accession number. Physically it is an accession-numbered folder containing metadata.json (the normalized EDGAR submission header) plus the primary notice document (HTML or, in a minority of cases, PDF) and the combined submission text file produced by EDGAR.
Registered management investment companies that maintain a fidelity bond under Rule 17g-1 — open-end funds, closed-end funds, ETFs organized as registered investment companies, and business development companies — must file the form when a claim or settlement occurs under that bond. The fund is the filer even though the insurance carrier and the investment adviser may be named inside the notice.
Filing is triggered either by a claim being made under the fidelity bond (Rule 17g-1(g)(2)) or by receipt of the terms of any settlement (Rule 17g-1(g)(3)). The notice must reach the Commission within five days of the triggering event, and there is no materiality threshold — any claim or settlement, regardless of dollar size, triggers the obligation.
The dataset begins in January 2016, corresponding to EDGAR-era records tagged under the 40-17GCS form type, and runs to the present. Earlier claim and settlement notices under Rule 17g-1(g) were filed on paper and predate this electronic form-type tagging.
The dataset is distributed as monthly ZIP containers partitioned under a YYYY/YYYY-MM.zip scheme. Inside each container, accession-numbered folders contain HTML, JSON, and PDF files corresponding to the metadata.json header, the primary 40-17GCS notice, and the combined submission text file.
Both forms are filed under Rule 17g-1 and concern the same fidelity bond, but they capture different moments in its lifecycle. Form 40-17G is a periodic filing that transmits the executed bond, any joint insured bond agreement, and related board approvals, showing that coverage exists. Form 40-17GCS is event-driven and shows when that coverage has been tested by a specific claim or settlement.