The Form N-18F1 Files Dataset is the complete EDGAR archive of notifications by which registered open-end management investment companies elect to rely on Rule 18f-1 under the Investment Company Act of 1940. One record represents a single EDGAR submission — either an original Form N-18F1 notification or a Form N-18F1/A amendment — materialized as one accession-number folder containing a normalized metadata.json together with the original primary documents the filer transmitted to EDGAR. The filer is the registrant itself: an open-end mutual fund trust, corporation, or series company that has chosen to commit irrevocably to redeem shares in cash up to the lesser of $250,000 or one percent of net asset value per shareholder during any 90-day period, while preserving the right to redeem larger amounts in kind. Coverage begins on January 1, 1994 — the start of EDGAR availability for this form — and extends through the most recent monthly refresh, with filings packaged inside monthly ZIP containers.
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 assembles every Form N-18F1 and Form N-18F1/A submission accepted by EDGAR from January 1994 to the present. Form N-18F1 is the "Notification of Election Pursuant to Rule 18f-1 under the Investment Company Act of 1940" — a one-time, perpetual election by which an open-end fund commits, irrevocably, to pay in cash all redemption requests by any one shareholder of record up to the rule's floor (the lesser of $250,000 or 1% of net asset value over any 90-day period). Above that floor, the registrant retains the right to satisfy redemptions in kind by distributing portfolio securities. Form N-18F1/A is the amendment vehicle, used most often to refresh the Schedule A list of series covered by the election after a fund is added, merged, liquidated, or renamed inside a series trust.
For each accession, the dataset preserves the structured EDGAR submission header — normalized into a metadata.json — together with the original primary documents from the submission, principally the SGML-wrapped notification document. Image files originally submitted to EDGAR (corporate logos, scanned letterhead, raster signature graphics) are excluded; everything else from the original submission is preserved. The file types found across the historical range are TXT, JSON, HTML, and PDF, with HTML/HTM dominating modern filings, plain text dominating filings from the mid-to-late 1990s, and PDF appearing only when filers attach separately produced exhibits such as a signed cover page or board certification. Records are distributed inside monthly ZIP containers, one per calendar year-month.
One record in the Form N-18F1 Files Dataset is a single EDGAR submission of either a Form N-18F1 notification or a Form N-18F1/A amendment, materialized on disk as one accession-number folder. The folder bundles the EDGAR submission header for that accession — normalized into a structured metadata.json — together with the original primary documents the filer transmitted to EDGAR, principally the SGML-wrapped notification of election under Rule 18f-1 of the Investment Company Act of 1940. Each record is therefore both a structured metadata object and a small package of source documents tied to one accession number, one registrant CIK, and one Rule 18f-1 election event.
Section 18(f) of the 1940 Act prohibits an open-end investment company from issuing any senior security; the SEC has long taken the position that an open-end fund's right to satisfy redemptions in kind, rather than in cash, can implicate that prohibition unless the fund either pays redemptions entirely in cash or makes a public, irrevocable commitment to do so up to a defined threshold. Rule 18f-1 provides that defined threshold. By filing Form N-18F1, the registrant elects, irrevocably, to commit itself to pay in cash all redemption requests by any one shareholder of record, limited during any 90-day period to the lesser of (i) $250,000 or (ii) one percent of the net asset value of the registrant at the beginning of such period. Above that threshold, the registrant retains the right to satisfy redemptions wholly or partly by distributing portfolio securities in kind.
The notification is a one-time, perpetual election: once filed, it remains in force for the registrant for the life of the company unless the registrant files a Form N-18F1/A to amend it. As a result, the body of the filing is short, formulaic, and largely standardized across registrants. Form N-18F1/A is used to update an existing notification — most often to refresh the Schedule A list of series covered by the election following the addition, merger, or liquidation of a fund within a series trust, or to reflect a registrant name change after a reorganization. An amendment is structurally a complete restatement of the notification rather than a redline against the prior version.
Records are distributed inside monthly ZIP containers, one ZIP per calendar year-month. Unzipping a container yields a single year-month folder (for example 2025-10/) whose direct children are accession-number subfolders named with the 18-digit, dashless accession number (for example 000093041325003181/). Each accession folder is one record and always contains:
metadata.json — a structured JSON object describing the EDGAR submission header and document manifest. Always present..htm file containing the N-18F1 notification. Older accessions may contain a flat .txt notification or, occasionally, a PDF exhibit attached by the filer.Image files originally submitted to EDGAR (corporate logos, scanned letterhead, raster signature graphics) are excluded from the dataset; everything else from the original submission is preserved.
metadata.json contentThe metadata file mirrors the EDGAR submission header and adds dataset-level convenience fields. The fields carried per record include:
formType — the form type string, either N-18F1 or N-18F1/A.accessionNo — the dashed accession number, e.g. 0000930413-25-003181.effectivenessDate — the date on which the filing becomes effective, in YYYY-MM-DD. For N-18F1, this normally equals the acceptance date.filedAt — the ISO-8601 timestamp of acceptance by EDGAR, including the Eastern Time offset.description — a human-readable filing description, typically "Form N-18F1 - Notification of election [Rule 18f-1]".linkToFilingDetails — a direct URL to the primary HTML document on sec.gov.linkToTxt — URL to the EDGAR complete-submission .txt rendition.linkToHtml — URL to the EDGAR filing-index HTML page.linkToXbrl — XBRL link when applicable; for N-18F1 this is essentially always empty because the form does not carry structured financial data.documentFormatFiles — an array of document descriptors, one per file in the EDGAR submission, with sequence, size, documentUrl, type, and an optional description. For N-18F1 this array typically lists the primary .htm notification and the EDGAR-generated complete-submission .txt.dataFiles — an array of structured data files; empty for this form.seriesAndClassesContractsInformation — an array of series/class identifier records; typically empty for N-18F1, since the form does not require structured series tagging in the EDGAR header.entities — an array of one or more filer entity objects describing the registrant(s) on the submission. Each entity object carries companyName (including the EDGAR role suffix such as (Filer)), cik, fileNo (the Investment Company Act file number, formatted 811-XXXXX), irsNo, stateOfIncorporation, fiscalYearEnd (MMDD), act (always 40 for the Investment Company Act of 1940), type (the form type), and filmNo (the EDGAR film number).id — an internal hexadecimal record identifier.The entities array is the principal place where registrant identity is structured. For a stand-alone fund this normally has one entry; for a multi-series trust the trust itself appears as the filer, and the underlying series are typically not enumerated in the metadata at all — they appear instead in Schedule A inside the notification document.
The substantive content of the record lives in the primary document inside the accession folder — almost always a .htm file in modern filings, a .txt file in early filings. The document is wrapped in EDGAR's standard SGML envelope, with <DOCUMENT>, <TYPE>N-18F1 (or N-18F1/A), <SEQUENCE>1, <FILENAME>..., and <TEXT> tags surrounding the rendered body. The body itself is short — usually one to two pages — and follows a strongly stereotyped layout:
Caption block. A centered three-line caption identifying the filing: "UNITED STATES SECURITIES AND EXCHANGE COMMISSION", "Washington, D.C. 20549", and "NOTIFICATION OF ELECTION PURSUANT TO RULE 18f-1 UNDER THE INVESTMENT COMPANY ACT OF 1940". Many filings add the registrant's Investment Company Act file number (811-XXXXX) directly under the caption.
Registrant identification. The exact legal name of the open-end investment company making the election. For a multi-series trust this is the trust name; for a stand-alone fund it is the fund name. The address of the registrant's principal office is sometimes included immediately after the legal name.
Election paragraph (the operative text). A single short paragraph stating that the registrant, in conformity with Rule 18f-1 under the Investment Company Act of 1940, hereby notifies the Commission of its election to commit itself to pay in cash all requests for redemption by any shareholder of record, limited in amount with respect to such shareholder during any 90-day period to the lesser of (i) $250,000 or (ii) one percent of the net asset value of the registrant at the beginning of such period. The paragraph commonly continues by reserving the right to satisfy any redemption demand above those thresholds, in whole or in part, by distribution in kind of portfolio securities, and characterizes the election as irrevocable. The legal language is largely formulaic across filers, with only minor stylistic variation.
Signature block. The execution block contains the city and state of execution, the date of execution, the registrant's printed name, the signer's signature (rendered in HTML as a typed name beneath a "/s/" token, or as a scanned graphic in older filings), and the signer's printed name and title. Signers are typically a senior officer of the trust or fund — President, Treasurer, Secretary, Chief Compliance Officer, or General Counsel. Many filings include a second signature attesting the execution, again with printed name and title.
Schedule A (when applicable). When the registrant is a multi-series trust, the notification almost always appends a Schedule A enumerating each individual series or fund covered by the election by full legal name. Schedule A may be presented as a numbered list, a bulleted list, or a small two- or three-column table. Its presence is the only place series-level granularity is captured: the structured seriesAndClassesContractsInformation block in the metadata is normally empty for this form, so Schedule A is the authoritative record of which funds the election applies to.
Because the document is short and standardized, the rendered body is small — typically a few kilobytes of substantive text wrapped in HTML scaffolding.
For each accession the dataset preserves the complete EDGAR-submitted document set — the primary notification (HTML or plain text), any complete-submission .txt rendition, and any PDF exhibits — together with a normalized metadata.json carrying the EDGAR header, document manifest, registrant identifiers, and dataset bookkeeping. The accession folder therefore contains everything needed to reconstruct both the legal content and the provenance of the filing: the operative election text, the registrant's CIK and 1940 Act file number, the registrant's state of incorporation and fiscal year-end, the filer entity profile, the signing officer (recoverable from the document body), the date and place of execution, and any Schedule A enumerating covered series.
Two categories of content are not present inside an accession folder. First, image files originally submitted alongside the notification (corporate logos, scanned letterhead, raster signature graphics) are excluded by the dataset. This omission rarely affects substantive content because the legal text and signatures are almost always carried as machine-readable HTML or text rather than as images. Second, content that is part of the EDGAR ecosystem but external to this submission — full-text search indexes, the registrant's separate registration statements (Form N-1A and post-effective amendments under Rule 485), Form N-CSR and N-CSRS shareholder reports, prospectus and SAI filings under Rule 497, Form N-PX proxy-vote records, and any related no-action correspondence — is not bundled into N-18F1 records, even when it concerns the same fund. Each record is scoped narrowly to one notification accession.
Amendment records share the same on-disk anatomy as original notifications: an accession folder, a metadata.json with formType set to N-18F1/A, and the same SGML-wrapped notification document layout. The substantive differences live inside the body. An amendment may restate the operative election paragraph verbatim, change the registrant name (typically following a trust reorganization or rebrand), adjust the principal-office address, or — most commonly — replace Schedule A with an updated list of covered series, usually because new series have been added to a trust or existing series have been merged or liquidated. Amendments do not carry a delta or redline against the prior notification; each N-18F1/A is a self-contained restatement, and reconstructing the history of a trust's covered-series list requires reading successive N-18F1 and N-18F1/A records under the same CIK in chronological order.
Form N-18F1 has been filed electronically through EDGAR since the mid-1990s, and the dataset spans the full history of those filings. The presentation format has evolved through three roughly successive eras:
1994 through the late 1990s — plain ASCII text. The earliest notifications are submitted as flat .txt documents wrapped only in the SGML <DOCUMENT> envelope, with no HTML markup. The caption, registrant name, election paragraph, signature block, and Schedule A are rendered using monospaced text, hand-laid line breaks, underscore-based underlining, and centered captions produced with leading whitespace. Signatures are represented by typed names following a /s/ token. Records from this era are typically a single text file plus the EDGAR header.
Late 1990s through the early 2010s — HTML adoption. As EDGAR began accepting HTML, filers transitioned to producing the notification as an HTM document inside the SGML envelope. Layout shifted from monospaced text to proportional fonts, with paragraph tags, basic HTML tables for Schedule A, and centered headings produced with <center> or simple inline styling. The substantive legal content was unchanged; only the rendering layer evolved.
Mid-2010s to present — modern HTML with embedded styling. Contemporary filings are HTML documents with inline CSS, often using table-based layouts for the caption block and Schedule A. PDF attachments occasionally appear when a filer attaches a separately produced signed cover page or a board resolution, but the primary notification almost always remains an HTML document.
Several nuances matter when working with these records.
seriesAndClassesContractsInformation block in metadata.json is normally empty for this form, Schedule A is the authoritative source for series-level coverage and must be parsed from the rendered notification.effectivenessDate and filedAt in metadata.json. The execution date inside the document body is normally the same day or one day earlier, but the header timestamp is the canonical reference.Each record is a Form N-18F1 (or N-18F1/A amendment) submitted to EDGAR by a registered open-end management investment company. The filer is the registrant itself — the trust, corporation, or series company registered under the Investment Company Act of 1940 — not its adviser, distributor, or transfer agent.
Filing is elective, not mandatory. No fund is required to file N-18F1; a fund files only if it chooses to opt into the Rule 18f-1 safe harbor. A fund that never elects simply never appears in this dataset.
Outside the population:
The record exists because a fund has affirmatively elected to rely on Rule 18f-1. The mechanics:
Funds make the election for operational reasons:
Amendments are housekeeping updates to a previously filed notification. Typical triggers:
Amendments do not modify the substantive cash-redemption commitment itself, which is fixed by Rule 18f-1.
The most useful comparisons to Form N-18F1 are other investment-company forms that touch redemption policy, fund operations, or §17/§18(f) exemptive territory.
Overlap: Form N-1A's Statement of Additional Information typically describes the same redemption policy, often referencing the Rule 18f-1 commitment in narrative form. A reader can usually infer from the SAI whether the fund operates under the safe harbor.
Key difference: N-1A is a continuously updated registration document covering objectives, fees, risks, financial highlights, and policies; N-18F1 is a single-purpose notification that legally perfects the 18f-1 election. The SAI describes the policy; N-18F1 establishes it on the record.
Confusion risk: Researchers searching N-1A for a definitive list of funds that have made the 18f-1 election will only find narrative disclosure, not the operative filing. N-18F1 is dispositive; prospectus language is not.
Overlap: Form N-2 is the structural counterpart to N-1A for management investment companies.
Key difference: Rule 18f-1 applies only to open-end funds with a §2(a)(32) redemption obligation, so closed-end funds, interval funds, and tender offer funds never file N-18F1. They manage limited repurchase mechanics under Rule 23c-3 or Rule 13e-4.
Confusion risk: A user searching for redemption-policy filings across the full registered-fund universe should treat N-2 filers as categorically outside the N-18F1 population.
Overlap: Semi-annual and annual reports may include footnote disclosure of in-kind redemption activity or redemption practices.
Key difference: N-CSR is a recurring, retrospective financial report; N-18F1 is a one-shot regulatory election. N-CSR can show whether a fund actually redeemed in kind during a period; N-18F1 shows only that the fund has reserved the right to do so under the safe harbor.
Confusion risk: N-CSR is the wrong source for confirming election status and the wrong source for the election date; it documents conduct, not the underlying legal commitment.
Overlap: N-CEN collects structured operational data and includes some yes/no indicators tied to redemption practices and rule reliance.
Key difference: N-CEN is annual, structured, and panel-style across all registered funds; N-18F1 is event-driven, filed only at the moment of election, and only by funds making it. N-CEN supports cross-sectional fund-attribute analysis; N-18F1 is the authoritative source for identifying who elected and when.
Confusion risk: N-CEN's redemption-related items can look like a substitute for N-18F1, but they reflect ongoing self-reporting rather than the perfected election itself.
Overlap: N-PORT supports the Rule 22e-4 liquidity framework, which is the modern operational counterpart to the redemption-management concerns Rule 18f-1 addresses.
Key difference: N-PORT is high-frequency, granular, and quantitative — holdings, risk metrics, liquidity classifications. N-18F1 is a one-time qualitative notification. N-PORT shows how a fund meets redemption demand day-to-day; N-18F1 sets the legal ceiling on its cash redemption commitment.
Confusion risk: Liquidity-classification data in N-PORT is sometimes mistaken for evidence of an 18f-1 commitment; the two regimes operate on different axes (operational liquidity vs. statutory cash floor).
Overlap: 40-APP applications and the resulting Commission orders also govern redemption flexibility and capital-structure questions, including in-kind redemption arrangements that go beyond Rule 18f-1.
Key difference: Rule 18f-1 is a self-executing safe harbor entered by filing N-18F1 and accepting the $250,000 / 1% NAV floor. A 40-APP is a bespoke request requiring Commission action and producing a tailored order. The two are alternative regulatory paths, not parallel disclosures.
Confusion risk: Funds with non-standard in-kind or affiliated-transaction relief appear in 40-APP filings and Investment Company Act release notices, not in N-18F1. Mixing the two populations distorts any analysis of redemption regimes.
Overlap: ETFs are technically open-end funds and disclose redemption practices on N-1A.
Key difference: Rule 6c-11 (adopted 2019) codifies ETF creation/redemption in kind through authorized participants and supersedes the prior patchwork of individual exemptive orders. The 18f-1 cash-floor mechanic is not the operative redemption framework for ETFs; their custom basket and in-kind practices are disclosed under 6c-11 on N-1A.
Confusion risk: A user expecting the N-18F1 dataset to cover ETF redemption mechanics will find it dominated by traditional mutual funds. ETF redemption practice lives in the 6c-11 / N-1A channel; the two regimes are complementary, not overlapping in their core mechanics.
Form N-18F1 is the only filing whose sole legal purpose is to perfect a fund's election to rely on Rule 18f-1's redemption safe harbor. It is not a registration statement (N-1A, N-2), not a periodic report (N-CSR), not a structured census (N-CEN), not a portfolio or liquidity disclosure (N-PORT), and not a request for individualized exemptive relief (40-APP). Other filings may describe redemption policy; only N-18F1 establishes the §18(f) safe-harbor commitment as a matter of record, making this dataset the authoritative source for identifying which open-end funds have made the election and when.
A small set of legal, operations, examination, and research roles consult the Form N-18F1 Files Dataset, each focused on different parts of the record.
Use the dataset as the authoritative answer to: does this trust have an N-18F1 on file, does Schedule A cover every current series and class, and has it ever been amended. They pull metadata.json for CIK, registrant name, accession number, and filing date, read the election language to confirm it tracks the rule's text, and diff Schedule A against the current series lineup to decide whether an N-18F1/A is needed. Output: compliance-calendar entries, board liquidity-risk reports, and exam production binders.
Pull historical N-18F1 and N-18F1/A filings during fund onboarding, complex acquisitions, reorganizations, and series launches. They check that the election was made in the correct trust name, validate Schedule A scope, and confirm the signature block reflects authorized officers. The accession number and filing date anchor exhibit lists for closing memos, board minutes, and Rule 22e-4 liquidity program approvals. Where a survivor inherits a predecessor's trust, they decide whether to refresh the election.
Operationalize the threshold itself. Before configuring shareholder-account systems to route requests above the lesser-of test into an in-kind workflow, ops supervisors confirm an N-18F1 exists for the trust (CIK and registrant in metadata.json) and that the redeeming series appears on Schedule A. The dataset feeds procedure manuals, transfer-agent service agreements, and large-redemption exception runbooks.
Use the dataset during liquidity-risk and redemption-practice exams to verify that funds invoking the rule actually filed and that Schedule A covers every series in the current registration statement. Examiners flag series listed in N-1A but missing from Schedule A, check the signature block and filing date for proper execution and timeliness, and use findings to support deficiency letters or enforcement referrals.
For institutional in-kind programs on non-ETF products, legal and compliance staff cite the election language as the legal basis for delivering securities rather than cash above the threshold. They confirm Schedule A coverage of each impacted series and use the filing date to show the election predates the contested redemption. The record anchors counterparty diligence responses and SAI disclosure on redemption-in-kind procedures.
Build long-run panels of Rule 18f-1 elections from 1994 to present by joining CIK and filing-date fields to holdings, flow, and performance data. They test whether elected funds behave differently in stress periods, whether N-18F1/A amendments cluster around regulatory events, and how Schedule A coverage tracks fund-complex growth. Outputs include peer-reviewed liquidity research, comment letters, and policy briefs.
Index the structured fields in metadata.json for query by CIK, registrant, filing date, and form type, and run full-text search across election language and Schedule A series. They surface election-status flags on registrant profiles, fire alerts on N-18F1/A amendments, and ship normalized Schedule A entries for entity resolution against series identifiers.
In summary, counsel and compliance staff use the dataset to confirm and maintain elections; ops teams use it to enforce the redemption threshold; SEC staff use it to test compliance; buy-side legal teams use it to defend in-kind programs; researchers use it to study fund liquidity; vendors use it to power compliance search. The metadata identifiers locate the filing, the election language defines the commitment, the signature block evidences authority, and Schedule A controls scope.
The dataset's value is concentrated in a few operational workflows that turn on three things: the registrant identifiers in metadata.json, the election paragraph in the notification body, and the Schedule A series list. The use cases below reflect the work practitioners actually run against it.
Fund counsel and compliance staff parse Schedule A from the latest N-18F1 or N-18F1/A under a trust's CIK and diff the series list against the funds currently registered on N-1A. Series present in the registration statement but absent from Schedule A flag a missing amendment; series on Schedule A but no longer registered indicate stale coverage. The output is a compliance calendar entry to file an N-18F1/A and an exhibit for the next board liquidity-risk report.
Transfer agents and fund administrators query metadata.json by CIK and formType to confirm that an N-18F1 exists for a trust before turning on routing rules that send redemption requests above the lesser-of-$250,000-or-1%-NAV threshold into the in-kind path. They confirm the redeeming series appears on Schedule A and capture the accessionNo and filedAt timestamp in the transfer-agent procedure manual and large-redemption runbook.
Academic and policy researchers join entities[].cik, effectivenessDate, and formType across all N-18F1 and N-18F1/A records to build a CIK-keyed panel of original elections and amendments from 1994 to present. The panel is merged with N-PORT holdings, N-CEN attributes, and flow data to test whether elected funds behave differently in stress windows and whether N-18F1/A amendments cluster around regulatory events such as the adoption of Rule 22e-4.
When a trust reorganizes, acquires another fund family, or launches new series, outside counsel pulls the chronological N-18F1 and N-18F1/A history under the predecessor and successor CIKs. They verify the election was made in the surviving trust name, check that the signature block names an authorized officer, and decide whether the inherited election covers the new series or whether a fresh N-18F1/A restating Schedule A is required at closing. Accession numbers and filing dates feed the closing-memo exhibit list and board-minute attachments.
Data vendors index metadata.json fields (accessionNo, cik, companyName, fileNo, filedAt, formType) to surface a Rule 18f-1 election flag on each registrant profile and to fire alerts whenever a new N-18F1/A is filed under a watched CIK. Full-text indexing of the election paragraph and parsed Schedule A entries lets subscribers search by series name and resolve those entries against series identifiers used in N-1A and N-CEN.
Examination staff use the dataset to verify that funds invoking the safe harbor in their SAI actually filed an N-18F1 and that Schedule A covers every series in the current N-1A. They cross-check the execution date and signer title in the document body against board authorization records, and use missing-series or stale-amendment findings to support deficiency letters or enforcement referrals.
The Form N-18F1 Files Dataset is available through three access methods: a JSON index endpoint for metadata and container discovery, a full-dataset archive download, and per-container downloads.
Dataset Index JSON API: https://api.sec-api.io/datasets/form-n18f1-files.json
This endpoint returns dataset-level metadata along with a complete listing of available container files. Returned fields include the dataset name, description, last updated timestamp, earliest sample date, total record count, total size in bytes, covered form types (N-18F1 and N-18F1/A), container format (ZIP), and the file types contained inside each container (TXT, JSON, HTML, PDF). Each entry in the containers array provides the container key, size, record count, last updated timestamp, and direct download URL. This endpoint does not require an API key.
The response can be polled to monitor which containers were updated in the most recent refresh run, allowing downstream pipelines to incrementally pull only the containers that changed since the last sync.
Example response:
1
{
2
"datasetId": "1f13365b-9ae0-6994-a50f-d0972e61872d",
3
"datasetDownloadUrl": "https://api.sec-api.io/datasets/form-n18f1-files.zip",
4
"name": "Form N-18F1 Files Dataset",
5
"updatedAt": "2026-04-15T11:58:26.924Z",
6
"earliestSampleDate": "1994-01-01",
7
"totalRecords": 1326,
8
"totalSize": 2846030,
9
"formTypes": ["N-18F1", "N-18F1/A"],
10
"containerFormat": "ZIP",
11
"fileTypes": ["TXT", "JSON", "HTML", "PDF"],
12
"containers": [
13
{
14
"downloadUrl": "https://api.sec-api.io/datasets/form-n18f1-files/2026/2026-04.zip",
15
"key": "2026/2026-04.zip",
16
"size": 13818783,
17
"records": 154,
18
"updatedAt": "2026-04-15T11:58:26.924Z"
19
}
20
]
21
}
Download Entire Dataset: https://api.sec-api.io/datasets/form-n18f1-files.zip?token=YOUR_API_KEY
Use this URL to download the complete dataset archive in a single request, covering all filings from the earliest sample date (1994-01-01) through the latest refresh. This endpoint requires an API key.
Download Single Container: https://api.sec-api.io/datasets/form-n18f1-files/2026/2026-04.zip?token=YOUR_API_KEY
To retrieve a specific monthly partition rather than the full archive, request the individual container using the key value from the index JSON. This is useful for incremental updates and selective backfills. This endpoint requires an API key.
The dataset covers Form N-18F1, the "Notification of Election Pursuant to Rule 18f-1 under the Investment Company Act of 1940," along with its amendment counterpart Form N-18F1/A. By filing N-18F1, an open-end fund commits irrevocably to redeem shares in cash up to the lesser of $250,000 or 1% of net asset value per shareholder over any 90-day period, while reserving the right to satisfy larger redemptions in kind.
One record is a single EDGAR submission of either a Form N-18F1 notification or a Form N-18F1/A amendment, materialized on disk as one accession-number folder. The folder contains a normalized metadata.json describing the EDGAR submission header plus the original primary documents the filer transmitted to EDGAR (typically an SGML-wrapped HTML or plain-text notification, occasionally with a PDF exhibit).
No one is required to file it. Filing is elective: a registered open-end management investment company files Form N-18F1 only if it chooses to opt into the Rule 18f-1 safe harbor. Closed-end funds, business development companies, unit investment trusts, private funds under Sections 3(c)(1) or 3(c)(7), and foreign funds not registered under the 1940 Act are outside the eligible filer population.
A fund files N-18F1 once. The election is a one-time, perpetual, irrevocable notification with no annual or periodic refresh requirement. Subsequent N-18F1/A amendments are housekeeping updates — typically to add newly launched series to Schedule A, reflect a registrant name change after a reorganization, or correct administrative errors.
The dataset covers EDGAR filings of Form N-18F1 and Form N-18F1/A from January 1, 1994 — the start of EDGAR availability for this form — through the most recent monthly refresh. Rule 18f-1 dates to 1971, so original elections by older complexes that were filed on paper before 1994 are not in this dataset, although later EDGAR amendments may reference those paper originals.
Records are distributed inside monthly ZIP containers, one ZIP per calendar year-month. Inside each container, records are organized as accession-number subfolders, each containing a metadata.json plus the original primary documents. The file types found across the historical range are TXT, JSON, HTML, and PDF; image files originally submitted to EDGAR are excluded.
Form N-CEN is an annual, structured census filed by all registered funds and contains some yes/no indicators tied to redemption practices, but it reflects ongoing self-reporting rather than the perfected election. Form N-1A is a continuously updated registration statement whose Statement of Additional Information may describe a fund's 18f-1 commitment in narrative form. Only Form N-18F1 legally establishes the Rule 18f-1 election on the record, making this dataset the authoritative source for identifying which open-end funds have made the election and when.