The Form N-1 Files Dataset is a closed historical corpus of SEC Form N-1 and Form N-1/A registration statements filed on EDGAR by insurance company separate accounts organized as open-end management investment companies. Each record corresponds to one EDGAR accession number — a single Form N-1 original registration statement or a Form N-1/A amendment — and bundles a structured metadata.json index alongside the original SGML-wrapped EDGAR submission documents. The form was prescribed by 17 CFR 274.11 and operated as a dual-purpose registration under both the Securities Act of 1933 and the Investment Company Act of 1940; it has since been rescinded and consolidated into Forms N-1A, N-3, N-4, and N-6, leaving this dataset a closed-ended archive. EDGAR-based Form N-1 filings begin in April 1995, consistent with the phase-in of mandatory electronic filing for investment companies, and end at the deprecation of 17 CFR 274.11.
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 Form N-1 Files Dataset assembles every Form N-1 and Form N-1/A submission accepted by EDGAR during the active life of 17 CFR 274.11. Form N-1 was the SEC registration statement prescribed under both the Securities Act of 1933 and the Investment Company Act of 1940 for insurance company separate accounts organized as open-end management investment companys. Functionally, the form combined two registrations in one document: a 1933 Act registration of the variable interests being offered to contract owners and a 1940 Act registration of the separate account itself as a registered investment company. Form N-1 sits inside the broader N-series of investment-company forms but is narrower than Form N-1A, which covers open-end mutual funds generally. Form N-1/A denotes an amendment to a previously filed Form N-1 registration statement; amendments may be pre-effective amendments adding or restating disclosure before effectiveness, post-effective amendments updating the prospectus or statement of additional information after effectiveness, or technical amendments correcting earlier filings.
Coverage begins in April 1995 and stops at the rescission of 17 CFR 274.11. The dataset is delivered as monthly ZIP containers organized under a YYYY/YYYY-MM/ layout; the file types found inside the dataset are TXT, JSON, and HTML. TXT carries SGML-wrapped EDGAR documents whose bodies are plain ASCII text, HTML (as .htm or .html) carries SGML-wrapped EDGAR documents whose bodies are HTML, and JSON carries the per-record metadata file. Image binaries that may have accompanied the original submission are excluded.
The substantive content of a Form N-1 filing follows the three-part documentary structure used across open-end fund registration practice:
A single record in this dataset corresponds to one EDGAR accession number for a Form N-1 or Form N-1/A filing — that is, one discrete submission to the Commission identified by a unique accession identifier. Each record materializes as a folder named with the digits-only accession number (for example 000152137312000045), nested inside a YYYY/YYYY-MM/ year-month root within the dataset's monthly archive layout. Every record folder holds one metadata.json describing the filing plus the full set of original EDGAR submission documents that accompanied it, with image binaries excluded. The record therefore packages two parallel layers: a structured JSON description of the filing (form type, timestamps, filer entities, document inventory, file-number assignments, EDGAR back-links) and the raw submission documents themselves in their original SGML-wrapped EDGAR form.
Each record folder contains exactly two structural elements:
metadata.json file that is always present and acts as the structured index of the submission, capturing filing-level identifiers, timing, the filer entity roster, file-number assignments under the 1933 Act and 1940 Acts, and an inventory of every document that was filed.<DOCUMENT> envelope. The primary document carries the prospectus, statement of additional information, and Part C content; ancillary documents, when present, carry exhibits such as charters, bylaws, opinions, and consents.Image binaries that may have accompanied the original submission are not included in the dataset. Everything else from the submission's document set is preserved in its original form, so that the textual content, tagged structure, and document boundaries of the original EDGAR submission remain reconstructable from the record.
metadata.json objectmetadata.json is a single JSON object describing the filing as a whole. Its fields fall into several functional groups.
Filing identification
formType — the EDGAR form code, "N-1" for an original registration statement and "N-1/A" for an amendment.accessionNo — the dashed accession number, e.g. "0001521373-12-000045", which uniquely identifies the EDGAR submission.filedAt — an ISO-8601 timestamp with timezone offset reflecting EDGAR acceptance time.description — a human-readable label for the form, such as "Form N-1 - Registration for open-end management investment companies".id — an opaque 32-character hexadecimal record identifier internal to the dataset.Source-document links (pointing back to EDGAR's canonical copies)
linkToFilingDetails — URL to the primary filing document under sec.gov/Archives/edgar/data/....linkToTxt — URL to the complete EDGAR submission text file, the concatenated SGML envelope around all documents in the submission.linkToHtml — URL to the EDGAR filing-index HTML page for the accession.linkToXbrl — URL to an XBRL instance where one exists; for Form N-1 this field is generally empty because the form's content was not subject to XBRL tagging during its active life.Document inventory
documentFormatFiles — an array with one object per document in the submission. Each object carries sequence (the EDGAR document sequence number), size (bytes, encoded as a string), documentUrl (the canonical EDGAR URL), description (free-text label such as "N-1" or an exhibit description), and type (the EDGAR document type tag such as N-1, EX-99, or other exhibit codes). This array mirrors the <DOCUMENT> envelopes inside the SGML submission.Filer entities
entities — an array of entity objects, one per filer or co-filer associated with the submission. Each object includes cik, companyName (often suffixed with a role marker such as "(Filer)"), fileNo (the SEC file number), irsNo, stateOfIncorporation, fiscalYearEnd (MMDD), act ("33" or "40", indicating which Act the file-number assignment relates to), type (the form type), and filmNo (the EDGAR film number). For Form N-1 the same legal filer characteristically appears twice — once with act set to "33" and once with "40" — paired with a 333- prefix file number for the 1933 Act registration and an 811- prefix file number for the 1940 Act registration. These two rows describe parallel registrations of the same submission, not duplicate filings.Series/class and supplementary data
seriesAndClassesContractsInformation — an array carrying EDGAR series identifiers (S-prefixed) and contract identifiers (C-prefixed) when the filer participates in EDGAR's series-and-class identification scheme. For Form N-1 records this array is often empty, because many separate-account filers predate or do not use the framework that EDGAR introduced primarily for mutual-fund families.dataFiles — an array describing supplementary data files attached to the filing (for example structured datasets sitting alongside the prospectus documents). For Form N-1 records this array is generally empty.Every document file in a record is wrapped in the EDGAR SGML <DOCUMENT> envelope. The envelope is not HTML; it is a lightweight tag set EDGAR has used since the system's launch to delimit individual documents within a single submission. A typical envelope looks like:
1
<DOCUMENT>
2
<TYPE>N-1
3
<SEQUENCE>1
4
<FILENAME>n1a.txt
5
<DESCRIPTION>N-1
6
<TEXT>
7
... document body ...
8
</TEXT>
9
</DOCUMENT>
The header tags identify the document's role (<TYPE>), its position within the multi-document submission (<SEQUENCE>), the original filename inside EDGAR (<FILENAME>), and an optional human-readable label (<DESCRIPTION>). Everything between <TEXT> and </TEXT> is the document body. For Form N-1 filings the body is most often plain ASCII text containing the prospectus, SAI, and Part C narrative; in later filings the body is frequently an HTML document encoded inline. Where a submission carries multiple documents, the primary registration document is sequence 1 and exhibits follow as separate <DOCUMENT> envelopes (each in its own file in the per-record folder, or, for EDGAR's complete-submission text file, concatenated into one stream).
The body text exposes the substantive sections of a Form N-1 registration in roughly the following order:
In some submissions the entire registration body sits in a single text document; in others the prospectus, SAI, and individual exhibits each occupy their own <DOCUMENT> envelope tagged with EDGAR exhibit type codes (for example EX-99 variants).
Form N-1's three-part Part A / Part B / Part C structure remained anchored throughout the form's active life on EDGAR (April 1995 through deprecation), but the surrounding regulatory environment introduced several material changes that affect what a typical record contains:
seriesAndClassesContractsInformation array for filers who adopted it; earlier records simply lack this dimension.Because Form N-1 was a niche registration vehicle for insurance separate accounts, its filing volume is comparatively small and the structure of the typical record stayed recognizably similar across the form's lifetime, even as language conventions and exhibit lists evolved.
The format of the underlying EDGAR submissions tracks broader EDGAR format evolution rather than anything Form N-1 specific:
<DOCUMENT> envelopes. The prospectus, SAI, and Part C all appear as line-wrapped text inside one or more .txt documents, with tabular content rendered in fixed-width ASCII.<DOCUMENT> wrappers but with the <TEXT> block containing HTML markup. In the dataset this manifests as .htm or .html documents in later record folders.Across all eras, the SGML envelope tagging and the per-record metadata.json index remain consistent, so the structural addressability of documents (by sequence, type, filename, and description) is uniform regardless of whether the body of any given document is ASCII text or HTML.
formType "N-1/A" are complete EDGAR submissions in their own right: each amendment has its own accession number, its own metadata, and its own document set, even when much of the content restates or supplements an earlier registration. There is no implicit linking field in metadata.json joining an amendment to its predecessor; the relationship has to be inferred from filer identity (CIK), the SEC file numbers (333- for the 1933 Act registration, 811- for the 1940 Act registration), and filing chronology.entities — once with act "33" and once with "40" — reflecting the form's combined role as a 1933 Act and a 1940 Act registration. The two fileNo values identify parallel registrations of one submission, not duplicate filings..txt file, the cover page, Part A, Part B, and Part C may share one <TEXT> block, separated only by blank lines and ad-hoc headings. Section boundary detection therefore requires textual heuristics (heading regexes, item numbers, "PART B"/"PART C" markers) rather than reliance on tag structure.<DOCUMENT> envelope must still be stripped before an HTML parser is applied to the body.documentFormatFiles array, especially the combination of sequence, type, and description, is the authoritative inventory of what exists inside the record and lets a reader identify the primary registration document versus exhibits without parsing the SGML envelopes themselves.documentFormatFiles are encoded as strings rather than integers; downstream parsers expecting numeric types must cast them.seriesAndClassesContractsInformation and dataFiles arrays are typical for Form N-1 and reflect the scope of the form rather than missing data.Each record in this dataset is a Form N-1 or Form N-1/A registration filing made by an insurance company separate account organized as an open-end management investment company. The legal registrant on EDGAR is the separate account itself; the sponsoring life insurance company appears as depositor and, typically, as co-registrant for the variable contract interests being offered.
A separate account is a segregated pool of assets established by a life insurer to fund variable annuity contracts or variable life insurance policies. When that pool is operated on a managed, redeemable basis, it is treated as an investment company under the Investment Company Act of 1940 and must register on the form prescribed for its structure. For the managed open-end variant supporting variable contracts, that form was historically Form N-1.
Filer entities in this dataset therefore include:
EDGAR filer identifiers are normally assigned to the separate account, not to the insurer.
A Form N-1 record arises when a qualifying insurance separate account simultaneously:
Form N-1 is the dual-purpose registration statement that historically served both functions for this filer class.
Form N-1/A records are amendments to a prior Form N-1. They are filed in four recurring contexts:
Triggers are thus both event-driven (initial registration, material change, contract addition) and periodic (annual prospectus and financial-statement update for accounts in continuous offering).
Initial filings have no fixed calendar deadline; they precede the public offering of the contract. Recurring deadlines for amendments are driven by Section 10(a)(3) staleness limits, Rule 485 timing tracks (immediate-effective and 60-day-delayed), and Regulation S-X financial-statement currency requirements.
EDGAR-based Form N-1 filings begin in April 1995, consistent with the phase-in of mandatory electronic filing for investment companies. Earlier paper filings are not included. The form has since been rescinded: the SEC removed 17 CFR 274.11 and consolidated insurance-product registration onto Forms N-3, N-4, and N-6, leaving Form N-1A for non-insurance open-end funds. No new Form N-1 or Form N-1/A submissions are accepted, so the dataset is closed-ended.
Form N-1 sits inside the SEC's "N-series" investment company registration regime, where forms are differentiated by fund structure (managed company vs. unit investment trust), redemption mechanics (open-end vs. closed-end), and underlying contract type (mutual fund shares, variable annuity, variable life). Form N-1 occupied a narrow, now-historical slot: insurance company separate accounts organized as open-end management investment companies, prescribed by the rescinded 17 CFR 274.11.
Form N-1A — open-end management investment companies (mutual funds). The form most often confused with N-1. Both register open-end management investment companies under the 1940 Act and offer securities under the 1933 Act, and both packages include a prospectus, SAI, financial statements, and exhibits. The dividing line is the filer: N-1 was used exclusively by insurance company separate accounts; N-1A covers all other open-end management companies (retail/institutional mutual funds and open-end ETFs). After 274.11 was rescinded, separate accounts that would have filed N-1 migrated into N-1A, N-3, N-4, or N-6. As datasets, N-1A is large, current, and continuously updated; N-1 is small, closed, and historical.
Form N-3 — managed open-end separate accounts offering variable annuities. The nearest functional cousin: like N-1, N-3 is filed by insurance separate accounts organized as managed open-end companies. The distinguishing axis is contract type — N-3 is specifically for variable annuity separate accounts, while N-1 covered managed separate accounts that did not fall into the variable-annuity-specific N-3 slot. Pre-rescission, N-1 and N-3 should be treated as parallel tracks within the managed-separate-account universe.
Form N-4 — UIT separate accounts offering variable annuities. Differs from N-1 on two axes simultaneously: structure (UIT, not managed company) and contract (variable annuity). Because most modern variable annuity separate accounts are UITs investing in underlying mutual funds, N-4 is the dominant variable-annuity registration form and the population dwarfs N-1 and N-3.
Form N-6 — separate accounts offering variable life insurance. Typically UITs supporting variable universal life and other variable life contracts. Disclosure architecture overlaps with N-1, but substantive content centers on death benefits, cost of insurance, and policy mechanics — none of which appear in N-1 prospectuses.
Form N-2 — closed-end management investment companies. Included only because the form-number proximity invites confusion. N-2 covers closed-end funds (non-redeemable, often listed) and is not a substitute for N-1 on any axis.
The most important boundary for this dataset. Under the prior regime, 274.11 prescribed N-1 for insurance separate accounts organized as open-end managed companies, while 274.11A prescribed N-1A for all other open-end funds. The two forms shared a common ancestry but were maintained separately to reflect the distinct legal and operational character of insurance separate accounts (segregated asset pools supporting variable contracts) versus standalone mutual funds. When the SEC rescinded 274.11, Form N-1 ceased to be an accepted registration form, and successor filings flowed into N-1A, N-3, N-4, or N-6 according to each account's structure and contract. This rescission is why the dataset is a closed historical archive rather than an ongoing collection.
Rule 485 post-effective amendments (485APOS, 485BPOS). Most ongoing prospectus updates for open-end funds and separate accounts flow through Rule 485 amendments rather than new registration statements. The N-1/A submissions in this dataset are amendments to N-1 registration statements specifically; the broader 485 ecosystem is keyed to whichever registration form the entity uses today (N-1A, N-3, N-4, N-6). To follow a former N-1 filer's continuing disclosure, track its successor form's 485 series.
Form 24F-2 — annual notice of securities sold. A brief fee-and-counts notice filed annually under Rule 24f-2; not a registration or disclosure document. The same filer population overlaps with N-1 in EDGAR histories, but 24F-2 complements N-1 rather than substituting for it.
Rule 497 filings (497, 497K). Deliver definitive prospectuses, supplements, and summary prospectuses to EDGAR for compliance with prospectus-delivery requirements. Content overlaps with the prospectus inside an N-1 package, but 497 filings lack the full registration apparatus (exhibits, signatures, SAI in registration form). They can be a cleaner source for prospectus text alone, but cannot substitute for the registration statement itself.
Form N-1 is simultaneously narrow and obsolete: it covered only insurance company separate accounts organized as managed open-end investment companies, only while 17 CFR 274.11 was in effect. Every nearby form differs on at least one axis — filer type (N-1A excludes separate accounts), contract type (N-3 variable annuity, N-6 variable life), structure (N-4 UIT), or redemption mechanics (N-2 closed-end). None is a drop-in substitute. The Form N-1 Files Dataset is best understood as a closed corpus of a specific managed-separate-account registration regime — useful for longitudinal study of pre-rescission insurance separate accounts, but not a window into current variable-product or mutual-fund disclosure.
The Form N-1 Files Dataset is a closed corpus of insurance separate-account registration statements filed under the rescinded 17 CFR 274.11 regime. Users are professionals who need to reconstruct, compare, or interpret legacy variable-product disclosure, not anyone tracking current filings.
Compliance teams at life insurers and separate-account administrators retrieve the original registration history of contracts still in force. They use metadata.json accession, filing-date, and registrant fields to locate the correct N-1 or N-1/A in a filing chain, then read the prospectus and SAI for point-of-sale disclosure of mortality and expense risk fees, surrender charge schedules, sub-account options, and annuitization mechanics. Output: regulatory file memos and responses to state insurance department inquiries.
Outside counsel and in-house lawyers handling variable annuity and variable life matters compare prospectus language across N-1 and N-1/A filings to trace how death benefit options, transfer restrictions, dollar-cost-averaging features, and fund-of-funds structures were articulated pre-rescission. They focus on prospectus fee tables and exhibits containing participation agreements and contract forms. Output: opinion letters, no-action analogies, and successor filings on N-3, N-4, or N-6.
Plaintiffs' and defense teams in suitability, class action, and breach-of-fiduciary matters involving variable products use metadata.json filing dates and amendment chains to align disclosures with sales periods, then mine prospectuses and SAIs for representations on sub-adviser substitutions, expense allocations, and risk warnings. Forensic accountants test asset-value, unit-value, and reserve figures in the financial statements against contemporaneous internal records. Output: expert reports, deposition exhibits, and admitted chronologies.
Product development and disclosure-design teams compare predecessor N-1 content against current N-3, N-4, and N-6 templates to migrate legacy products and mine drafting precedent for new riders. They work the prospectus benefit and charge sections, SAI investment-policy language, and exhibits containing contract specimens. Output: redline mappings, internal drafting standards, and template libraries.
Financial-printer disclosure specialists and drafting consultants use the corpus as a template archive when preparing analogous filings on successor forms. They search metadata by registrant and filing date, then copy structural patterns from prospectus and SAI sections and adapt exhibit indices. Output: draft registration statements and amendment packages.
Rulemaking and examination staff use the corpus to understand exactly what the rescinded form required, comparing N-1 structures to current variable-product templates when scoping further amendments or contextualizing inspections of legacy contracts. Academic researchers studying separate-account regulation work across the full population, using metadata.json for filer-level and time-series cohorts and prospectus and exhibit text for qualitative coding. Output: staff economic analyses, journal articles, and policy monographs.
Vendors maintaining long-history separate-account and sub-account reference data parse metadata.json for filer keys, accession identifiers, and amendment lineages, and extract structured rows from prospectus fee tables and financial statement schedules. Output: normalized historical fee and product reference data delivered to insurance analytics and retirement-research clients.
Teams building retrieval-augmented systems for variable-product compliance, contract administration, and litigation review index the prospectus, SAI, and exhibit text to extend coverage into the pre-rescission period. They use metadata.json for document provenance and amendment threading, and treat the HTML and TXT documents as embedding chunks. Output: improved answer quality on legacy contract terms absent from current N-3, N-4, and N-6 filings.
The use cases below reflect the dataset's scope as a closed historical corpus: backward-looking workflows anchored in specific record components.
Compliance officers at life insurers identify the registrant CIK and 1940 Act file number (811- prefix) of a separate account whose contracts remain on the books, then filter metadata.json records on entities[].cik and entities[].fileNo and order them by filedAt to assemble the full N-1 and N-1/A sequence. The prospectus and SAI inside each accession provide the point-of-sale disclosure of mortality and expense risk fees, surrender charge schedules, and sub-account menus that applied during each sales window. Output: a date-aligned disclosure chronology used to answer state insurance department inquiries about legacy contracts.
Litigation teams in suitability and breach-of-fiduciary matters use filedAt and formType (N-1 versus N-1/A) to bracket which prospectus and SAI were effective on a given purchase date, then extract the relevant Part A risk and fee sections plus Part B sub-adviser and expense disclosures. Forensic accountants test the financial statements bound into the SAI (statement of assets and liabilities, statement of operations, financial highlights) against the carrier's contemporaneous unit-value and reserve records. Output: expert reports, deposition exhibits, and admitted disclosure chronologies.
Carrier product and disclosure teams pull the most recent N-1/A for a managed separate account, extract the Part A benefit and charge tables and the Part C exhibit list (declaration of trust, advisory agreement, distribution agreement, participation agreements), and redline them against current N-3, N-4, or N-6 templates. The contract specimens and rider language buried in EX-99 exhibits provide the source text for new filings under the post-rescission regime. Output: redline mappings, drafting precedent libraries, and successor registration drafts.
Academic researchers and data vendors iterate the full corpus, parsing fee-and-expense tables out of Part A and trustee/officer rosters and brokerage policies out of Part B to construct a panel keyed on registrant CIK, file number, and filedAt. The dual-Act entities rows (one with act "33", one with "40") supply both the 1933 Act 333- series and the 1940 Act 811- series identifiers needed to merge with EDGAR series and class data and with state insurance filings. Output: normalized historical fee and product reference data, journal articles on separate-account regulation, and policy monographs on the pre-rescission regime.
Teams building retrieval systems for variable-product compliance and contract administration index the SGML-wrapped prospectus, SAI, and exhibit documents as embedding chunks, using metadata.json (accessionNo, formType, filedAt, entities[].cik) for provenance and amendment threading. Section boundary heuristics for "PART A"/"PART B"/"PART C" markers handle older single-document ASCII filings, while HTML-bodied later filings are parsed after stripping the SGML envelope. Output: assistants that can answer questions about legacy contract terms (death benefit options, sub-adviser substitutions, dollar-cost-averaging mechanics) that no longer appear in current N-1A, N-3, N-4, or N-6 filings.
Regulatory counsel and reference-data teams target documentFormatFiles entries with EDGAR exhibit type codes (typically EX-99 variants) to extract the recurring exhibit set: investment advisory agreement, custodian agreement, distribution and underwriting agreement, opinions of counsel, consents of independent accountants, powers of attorney, and (in later filings) codes of ethics. Cross-referencing these exhibits against the entities array and Part B trustee disclosures reveals adviser, sub-adviser, custodian, and auditor relationships across the life of each separate account. Output: service-provider histories, governance datasets, and audit-trail support for examinations of legacy contracts.
Dataset Index JSON API: https://api.sec-api.io/datasets/form-n1-files.json
This endpoint returns dataset-level metadata (name, description, last updated timestamp, earliest sample date, total record count, total size, covered form types, container format, and file types) along with a list of every container file in the dataset. Each entry in the containers array carries the container's S3 key, size, record count, last updated timestamp, and direct download URL. Polling this endpoint is the recommended way to detect which containers were touched in the most recent refresh and to download only the changed containers on a daily basis. This endpoint does not require an API key.
Example response:
1
{
2
"datasetId": "1f13365b-9ae0-69f3-8780-015d516cfdfc",
3
"datasetDownloadUrl": "https://api.sec-api.io/datasets/form-n1-files.zip",
4
"name": "Form N-1 Files Dataset",
5
"updatedAt": "2026-04-15T18:15:11.815Z",
6
"earliestSampleDate": "1995-04-01",
7
"totalRecords": 938,
8
"totalSize": 20258683,
9
"formTypes": ["N-1", "N-1/A"],
10
"containerFormat": "ZIP",
11
"fileTypes": ["TXT", "JSON", "HTML"],
12
"containers": [
13
{
14
"downloadUrl": "https://api.sec-api.io/datasets/form-n1-files/1995/1995-04.zip",
15
"key": "1995/1995-04.zip",
16
"size": 1842311,
17
"records": 27,
18
"updatedAt": "2026-04-15T18:15:11.815Z"
19
}
20
]
21
}
Download Entire Dataset: https://api.sec-api.io/datasets/form-n1-files.zip?token=YOUR_API_KEY
Downloads the complete dataset as a single ZIP archive covering all Form N-1 and N-1/A filings from April 1995 onward. Inside the archive, each accession number folder contains a JSON metadata file plus the original EDGAR documents in TXT and HTML formats (image files excluded). This endpoint requires a valid sec-api.io API key.
Download Single Container: https://api.sec-api.io/datasets/form-n1-files/1995/1995-04.zip?token=YOUR_API_KEY
Downloads one monthly container ZIP instead of the full archive. Use this when iterating the containers array from the index API to fetch only specific time periods or only the containers whose updatedAt has changed since your last sync. This endpoint requires a valid sec-api.io API key.
Typical usage: for a one-time bulk load, hit the full dataset URL once. For ongoing maintenance, poll the index JSON daily, compare each container's updatedAt against your local copy, and re-download only the containers that changed.
The dataset covers SEC Form N-1 and its amendment variant Form N-1/A — the registration statement historically prescribed by 17 CFR 274.11 for insurance company separate accounts organized as open-end management investment companies. Form N-1 served as a dual-purpose registration under both the Securities Act of 1933 and the Investment Company Act of 1940.
Each record corresponds to one EDGAR accession number for a Form N-1 or Form N-1/A submission. The record materializes as a folder named with the digits-only accession number, containing a metadata.json index plus the full set of original EDGAR submission documents wrapped in their SGML <DOCUMENT> envelopes (image binaries excluded).
The legal registrant is an insurance company separate account organized as an open-end management investment company — a segregated asset pool established by a life insurer to fund variable annuity contracts or variable life insurance policies and operated on a managed, redeemable basis. The sponsoring insurance company appears as depositor and contract underwriter, and EDGAR filer identifiers are normally assigned to the separate account rather than the insurer.
The SEC rescinded 17 CFR 274.11 and consolidated insurance-product registration onto Forms N-3, N-4, and N-6, leaving Form N-1A for non-insurance open-end funds. After rescission, no new Form N-1 or Form N-1/A submissions are accepted, so the dataset is a closed historical corpus.
EDGAR-based Form N-1 filings begin in April 1995, consistent with the phase-in of mandatory electronic filing for investment companies, and continue through the rescission of 17 CFR 274.11. Earlier paper filings are not included.
The file types are TXT, JSON, and HTML. JSON carries the per-record metadata.json index; TXT carries SGML-wrapped EDGAR documents whose bodies are plain ASCII text (typical of earlier filings); and HTML (as .htm or .html) carries SGML-wrapped EDGAR documents whose bodies are HTML markup (typical of later filings). The dataset is delivered as monthly ZIP containers under a YYYY/YYYY-MM/ layout.
Both register open-end management investment companies under the 1940 Act and offer securities under the 1933 Act, but the dividing line is the filer. Form N-1 was used exclusively by insurance company separate accounts under the rescinded 17 CFR 274.11; Form N-1A covers all other open-end management companies, including retail and institutional mutual funds and open-end ETFs, and remains the active form. After rescission, separate accounts that would have filed N-1 migrated into N-1A, N-3, N-4, or N-6 depending on their structure and contract type.