The Form N-3 Files Dataset is a corpus of every Form N-3 registration statement and Form N-3/A amendment submitted to EDGAR from April 1996 to present. Form N-3 is the joint registration filing prescribed by 17 CFR 239.17a (Securities Act of 1933) and 17 CFR 274.11b (Investment Company Act of 1940) for insurance company separate accounts that are organized as management investment companies and that issue variable annuity contracts. Each record in the dataset is one complete EDGAR submission — identified by its 18-digit accession number — and contains both a structured metadata.json anchor and the as-filed document set (prospectus, Statement of Additional Information, financial statements, and exhibits) in the original SGML-wrapped TXT or HTML form. Filings are made by the separate account as registrant alongside the sponsoring life insurer (the depositor), making the dataset the canonical public record of internally managed variable annuity separate accounts and their contract terms over three decades.
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 captures the full population of Form N-3 and Form N-3/A submissions to EDGAR for insurance company separate accounts that are organized as management investment companys and that issue variable annuity contracts. Form N-3 is the narrow registration vehicle distinct from Form N-4 (separate accounts organized as unit investment trusts) and Form N-6 (variable life): it applies only to separate accounts whose underlying portfolios are managed directly within the separate account rather than through investments in shares of underlying mutual funds. A Form N-3/A is a pre-effective amendment or post-effective amendment to a previously filed N-3, ranging from a short corrective filing to a wholesale restated registration statement.
Coverage begins in April 1996, tracking the phase-in of mandatory electronic filing for investment company registrants, and continues to present. The use of Form N-3 has always been narrow because most variable annuity separate accounts are organized as unit investment trusts and register on Form N-4; the N-3 population is therefore small and skewed toward a limited set of insurer families that historically structured certain separate accounts as managed investment companies. The dataset is distributed as monthly ZIP container archives whose payload file types are TXT (the original SGML-wrapped document files, regardless of inner ASCII or HTML content), HTML (modern document bodies), and JSON (the per-record metadata.json anchors).
One record in the Form N-3 Files Dataset is one complete EDGAR submission of a Form N-3 registration statement or a Form N-3/A amendment, identified by its 18-digit accession number. Each record is materialized as a folder whose name is the dash-stripped accession number (for example 000095013603000955), nested inside a month-level parent folder named YYYY-MM/ that groups records by EDGAR filing month. Inside the folder sit a single metadata.json structured anchor and one document file per item submitted to EDGAR, with image attachments excluded. The record therefore captures both the as-filed content of one variable-annuity separate-account registration and a structured description of the filing's identity, filer entities, exhibit list, and per-document metadata.
The substantive content of a Form N-3 is dictated by the form's instructions, organized into three parts:
A typical N-3 submission therefore packages within one filing: the prospectus, the Statement of Additional Information, audited financial statements of the separate account and its portfolios, the depositor insurance company's general account financial statements (often incorporated by reference or attached), and a set of legal and accountant exhibits — most commonly opinions of counsel as to legality of the securities and consents from independent registered public accountants — alongside the underlying contract forms, distribution agreements, custody agreements, participation agreements, and powers of attorney listed in the exhibit index.
A single record is organized as two parallel layers linked by sequence number, file name, exhibit type, and description:
metadata.json file at the root of the accession folder describing the filing as an EDGAR transaction: form type, accession number, filing timestamp, links back to EDGAR-hosted artifacts, the per-document inventory, the data-file inventory, and the list of associated entities and their identifiers.file001.txt, file002.txt, file003.txt, …) carrying an SGML <DOCUMENT> envelope around either plain ASCII text (older filings) or HTML (more recent filings).Every entry in the metadata's documentFormatFiles[] array points to a concrete on-disk sibling file, except for one synthetic entry that describes the EDGAR "complete submission text file" hosted on sec.gov.
The metadata.json file is the canonical entry point for programmatic use of a record. Its top-level fields are:
formType — N-3 for an original registration statement or N-3/A for an amendment.accessionNo — the canonical EDGAR accession number in dashed form (for example 0000950136-03-000955).filedAt — the ISO-8601 EDGAR acceptance timestamp with timezone offset.description — the human-readable form description, typically Form N-3 - Registration statement for separate accounts (management investment companies).id — an opaque 32-character hex internal record identifier.linkToFilingDetails — sec.gov/Archives URL of the primary registration document.linkToTxt — sec.gov URL of the EDGAR full submission .txt file (the SGML concatenation of every document in the submission).linkToHtml — sec.gov URL of the EDGAR filing index page (-index.htm).linkToXbrl — URL of an XBRL instance if one exists.documentFormatFiles[] — the per-document inventory (see below).dataFiles[] — array of attached structured data files (XBRL/XML).entities[] — the array of filer, registrant, and subject entities involved in the filing (see below).Each documentFormatFiles[] entry describes one submitted document and carries:
sequence — the EDGAR sequence number as a string; the synthetic complete-submission row carries a single space.size — file size in bytes, as a string.documentUrl — absolute URL on sec.gov.description — EDGAR-supplied free-text label such as REGISTRATION STATEMENT, OPINION AND CONSENT OF COUNSEL, CONSENT OF PRICEWATERHOUSECOOPERS LLP, or Complete submission text file.type — the EDGAR document/exhibit code: N-3 for the primary document and EX-99.x, EX-12.(K) (opinion of counsel), EX-13.(L) (accountant consent), and similar codes for exhibits.Each entities[] entry describes one role on the filing. The companyName field carries the registered name with the EDGAR role suffix appended in parentheses ((Filer), (Subject), (Registrant)). For Form N-3 this typically resolves to two entities — the insurance-company depositor (the operating life insurer) and the separate account itself — each with its own ten-digit zero-padded cik. Additional fields include irsNo, fileNo (the SEC file number, such as a 333- 1933 Act registration paired with an 811- 1940 Act registration), filmNo, the form type the entity is associated with on this filing, act (the Act number, for example 33 for 1933 Act registrations), sic (the SIC code with its EDGAR description suffix, generally 6411 Insurance Agents, Brokers & Service or 6311 Life Insurance), stateOfIncorporation, and fiscalYearEnd as MMDD.
Sibling document files (fileNNN.txt) carry the actual registration content. Each file opens with a small EDGAR SGML envelope:
1
<DOCUMENT>
2
<TYPE>EX-12.(K)
3
<SEQUENCE>3
4
<FILENAME>file002.txt
5
<DESCRIPTION>OPINION AND CONSENT OF COUNSEL
6
<TEXT>
7
... payload ...
8
</TEXT>
9
</DOCUMENT>
The <TYPE>, <SEQUENCE>, <FILENAME>, and <DESCRIPTION> tags mirror the corresponding documentFormatFiles[] entry exactly, providing redundant in-document metadata. The body between <TEXT> and </TEXT> is the registration content. For older N-3 filings the payload is plain ASCII with <PAGE> markers indicating page breaks and embedded <TABLE><CAPTION>...<S>...<C>...</TABLE> blocks delimiting fixed-width financial tables; for more recent filings the payload is HTML, sometimes with embedded inline tables and styling. Image graphics that would otherwise accompany the registration (logos, contract-illustration figures) are excluded from the dataset by design.
Primary registration document (TYPE N-3). The first sequenced document is the registration statement itself. It opens with the EDGAR-style cover page identifying the registrant, the file numbers under the 1933 and 1940 Acts, the title of the securities being registered, and the calculation-of-registration-fee table where applicable. It then proceeds through Part A (the prospectus), Part B (the Statement of Additional Information), and Part C (Other Information). Each part is internally ordered by the items prescribed in the Form N-3 instructions: cover page, summary, fee table, financial highlights, separate account description, contract description, charges and deductions, investment policies, purchase and redemption procedures, and federal tax disclosure for Part A; management, brokerage, custodian, accountants, and performance methodology for Part B; and the exhibit index, undertakings, indemnification, and signatures for Part C. Audited financial statements of the separate account and the depositor insurance company are either embedded in the primary document or incorporated by reference, depending on filer practice.
Exhibits (TYPE EX-...). Subsequent sequenced documents are the exhibits enumerated in Part C. The exhibit codes follow the form-specific lettering of Item 32 (or its predecessor numbering for older filings): (a) charter documents, (b) by-laws, (c) underwriting/distribution contracts, (d) investment advisory contracts, (e) contract forms, (f) insurance company financial statements, (g) custodian agreements, (h) participation agreements, (i) other material contracts, (j) opinion of counsel as to legality of securities, (k) consents (including independent accountant consents), (l) financial statements omitted from Part B, and (m) powers of attorney. In practice the most consistently present exhibits are the legal opinion and the accountant consent; bulkier exhibits such as charter documents or distribution agreements are often incorporated by reference to prior filings rather than re-submitted.
Signature page. The registration is signed at the end of the primary document by the registrant (the separate account, executed on its behalf by an officer of the depositor), the depositor insurance company, and the principal officers and directors of the depositor required to sign by the form. Signatures are presented in plain text, often gathered under a power of attorney exhibit.
Complete submission text file. The synthetic documentFormatFiles[] row whose sequence is a blank string and whose description is Complete submission text file references the EDGAR full-submission .txt artifact rather than a file inside the accession folder; its documentUrl points back to sec.gov. It is included in the metadata for completeness but is not duplicated as a sibling file.
Every record carries the structured metadata.json and every TXT or HTML document filed in the EDGAR submission, in original SGML-wrapped form, with sequence numbering and exhibit typing preserved. The primary registration document, the prospectus and Statement of Additional Information embedded within it, the financial-statement content actually submitted as part of the registration, the legal and accountant exhibits, and the signature page are all present in the document files. The entities[] block provides the full set of EDGAR-recognized parties and their identifiers, sufficient to join the record against other EDGAR datasets keyed on CIK or file number.
linkToTxt URL.Form N-3 has been the variable-annuity registration vehicle for managed-portfolio separate accounts since well before EDGAR mandatory filing began for these registrants in the mid-1990s. Several substantive regulatory shifts over the dataset window (April 1996 onward) have shaped what appears inside individual records:
(a), (b), …), while modern filings use the EX-99.(letter) EDGAR exhibit code mapping. Both conventions are visible in the dataset depending on filing year.Form N-3 records span the full EDGAR formatting evolution. Filings from April 1996 through roughly the early 2000s are submitted as ASCII plain text inside the SGML <DOCUMENT> envelope, with <PAGE> markers delimiting page breaks and <TABLE><CAPTION>...<S>...<C>...</TABLE> blocks holding fixed-width financial tables. From the early 2000s onward HTML becomes the dominant payload format inside the same SGML envelope, with progressively richer styling and embedded HTML tables replacing the ASCII-art tables. The on-disk file extension remains .txt in many cases even when the payload is HTML, because EDGAR historically preserved the document filename as submitted; the file-types found in the dataset accordingly include both TXT and HTML. The metadata layer (metadata.json) is uniform JSON across the full date range and does not vary with the underlying payload format.
N-3/A) range from short corrective filings that contain only a cover page and a single replaced exhibit to comprehensive restatements that re-file the entire registration. The formType field flags amendment status but does not by itself indicate scope, which must be inferred from the document inventory and content.entities[] array typically carries both the depositor insurance company (filer) and the separate account (registrant/subject) with distinct CIKs. Joins on CIK should respect this multiplicity rather than assume a single party per filing.entities[] is delivered as a string with its description suffix and may contain unescaped HTML entities (for example &); consumers normalizing SIC values should account for this.<S>/<C> column-stub convention and require column-width-aware parsing rather than naive whitespace tokenization.<DOCUMENT> wrapper tags duplicate fields that already exist in metadata.json (sequence, type, filename, description), providing a redundant cross-check between the two layers when validating extraction pipelines..txt extension persists across both ASCII and HTML payloads, payload-format detection must be based on content sniffing or the <TYPE> and inner markup, not on the filename suffix.The legal filer is an insurance company separate account organized as a management investment company that issues variable annuity contracts. The separate account is the registrant on EDGAR. The sponsoring life insurance company (the depositor) establishes and funds the account, issues the contracts, and signs the filing alongside the registrant; its general account financial statements are included because contract guarantees rest on the insurer's claims-paying ability.
The eligible filer population is narrow:
Contract owners and annuitants are not filers; they are the offerees. Underlying portfolio funds referenced in the prospectus file their own registration statements (typically Form N-1A) and are outside this dataset.
Form N-3 is registration-driven, not periodic. There is no fixed external deadline; a record arises when the separate account needs to register or update its offering.
Amendment cadence is therefore set by the annual financials update, contract or operational changes, and staff review cycles, not by event-reporting deadlines of the kind that govern current reports. EDGAR records in this dataset begin in April 1996, tracking the phase-in of mandatory electronic filing for investment company registrants. The form itself was adopted in 1985.
Form N-3 sits within a tight family of investment company registration forms that share dual registration under the Securities Act of 1933 and the Investment Company Act of 1940 but apply to different product structures. The most useful comparisons distinguish N-3 by product type (variable annuity), organizational form (management investment company), and lifecycle stage (initial registration versus post-registration reporting).
The nearest neighbor. N-4 also registers variable annuity contracts issued through insurance company separate accounts, but it covers separate accounts organized as unit investment trusts (UITs) that invest in underlying registered funds. N-3 covers separate accounts organized as management investment companies that manage portfolios internally at the separate account level. The product is the same; the legal and operational structure is not. N-4 dominates the modern variable annuity market, so an N-3 dataset captures a narrow specialty population while N-4 captures the mainstream. Prospectus content overlaps in form (prospectus, SAI, separate account and insurer financials, exhibits) but differs in substance: N-3 describes internally managed sub-accounts; N-4 describes pass-through investments in underlying funds.
Registers separate accounts organized as UITs that offer variable life insurance, not variable annuities. Disclosures emphasize cost-of-insurance charges, death benefit options, and lapse mechanics rather than accumulation and annuitization. N-3 and N-6 share only the broader separate account framework; the product, organizational form, and disclosure focus all differ.
Registers open-end management investment companies (mutual funds and ETFs). Like N-3, it covers internally managed pooled vehicles with continuously issued redeemable interests under the 1933/1940 Act regime. The decisive difference is the wrapper: N-1A shares are sold directly as fund securities, while N-3 interests are sold only inside an insurance contract, which changes the tax treatment, distribution channel, and contractual mechanics. N-1A is not a substitute for N-3 research.
Registers closed-end management investment companies, including BDCs. Shares the 1940 Act management company classification with N-3 but applies to closed-end traded shares rather than open-ended separate account interests. Useful as context for the 1940 Act registration landscape but not a functional alternative.
Amendments to previously filed N-3 registration statements, including pre- and post-effective amendments used to update prospectuses, add or close investment options, refresh financials, or implement contract changes. N-3/A is included in this dataset and should be analyzed alongside N-3 as a single registration record; separating them understates cumulative disclosure activity per registrant.
Post-registration periodic filings, not substitutes for N-3. 24F-2 is the annual notice of securities sold and registration fee reconciliation. N-CEN is the annual structured census report for registered investment companies. Both record operational activity after the offering exists; N-3 establishes the offering itself. They complement N-3 across a registrant's lifecycle but carry entirely different content (fee math, structured census fields versus narrative prospectus and financial statements).
Some separate accounts historically filed audited financial statements as standalone submissions. These contain only the financials, whereas N-3 embeds financials within the full registration package alongside prospectus, SAI, and exhibits. Use standalone filings for financials in isolation; use N-3 for the complete registration narrative.
The Form N-3 Files Dataset is distinct because it captures one specific intersection: separate accounts organized as management investment companies that offer variable annuity contracts. That combination is uncommon in today's market, which is why the corpus is a narrow specialty population rather than a mainstream registration set. N-4 is the closest substitute for variable annuity research but covers a different organizational form; N-6 covers a different product; N-1A and N-2 cover non-separate-account management companies; 24F-2 and N-VPFS cover post-registration reporting. None substitute for N-3 when the research question concerns internally managed variable annuity separate accounts, but several are natural complements when assembling a full registrant or product-line view.
Form N-3 filings are the authoritative public record of variable annuity contracts issued through management-investment-company separate accounts. The dataset is used by a narrow set of professionals working on insurance product design, securities disclosure, audit, examination, and litigation.
Used to benchmark peer contract charges, M&E fees, administrative loads, CDSCs, and rider pricing. Focus: prospectus fee tables, contract-charge sections, and living/death-benefit descriptions. Supports fee positioning and new contract series design.
Used to draft and review N-3 registration statements and N-3/A amendments. Focus: risk-factor language, contract descriptions, voting-rights disclosure, SAI investment policies, and exhibits including participation, distribution, and custody agreements. Supports drafting, SEC comment responses, and peer-disclosure comparison.
Used to confirm how peers describe sales loads, surrender charges, exchange privileges, free-look terms, and affiliated-party arrangements. Focus: distribution sections, underwriting and selling-agreement exhibits, and SAI conflicts disclosure. Supports policy benchmarking and pre-filing review.
Used to compare presentation of separate-account and general-account financials. Focus: accounting policy footnotes, valuation disclosures, and related-party notes. Supports audit planning and disclosure-quality review.
Used to map the variable annuity universe, identify share classes, and track contract series through N-3/A amendment chains. Focus: cover-page contract descriptions, distribution narratives, and underwriter exhibits. Supports competitive intelligence and product-shelf analysis.
Used to pull the latest effective registration, prior amendments, and full exhibit sets for a given separate account. Focus: accession metadata, amendment history, and contract/policy exhibits. Supports examination prep and historical disclosure reconstruction.
Used in disputes over sales practices, fee disclosure, or rider performance to reconstruct what was disclosed at specific dates. Focus: fee tables, hypothetical expense examples, surrender schedules, and rider descriptions across successive amendments. Supports expert reports and damages models.
Used to read general-account financials bundled into N-3 filings and assess how variable annuity liabilities and guarantees sit on the insurer's balance sheet. Focus: general-account statements and rider-guarantee descriptions. Supports credit memos and capital-adequacy review.
Used as a structured corpus of contract-level disclosures back to 1996. Focus: fee tables, rider features, and amendment time series. Supports empirical work on fee evolution and disclosure complexity.
Used to ingest a bounded corpus for annuity comparison tools, advisor copilots, and compliance assistants. Focus: HTML/TXT document bodies, JSON accession metadata, and N-3/A amendment chains. Supports indexing, clause extraction, and grounded retrieval.
Used to maintain reference tables of separate accounts, contract series, fee schedules, and exhibit inventories. Focus: accession metadata, filer identifiers, and per-filing file lists. Supports normalized internal datasets queried by downstream analysts.
The Form N-3 dataset is small and specialized, but it supports a focused set of operational workflows in variable annuity disclosure, audit, examination, and analytics.
Pull the prospectus fee tables and Part A contract-charge sections from each N-3 and N-3/A to compare mortality and expense risk charges, administrative charges, contract maintenance fees, and CDSC schedules across peer registrants. Output: a peer-charge matrix used by product actuaries and pricing committees to position new contract series and justify fee changes in pre-filing review.
Walk the N-3 plus N-3/A amendment chain for a single separate account by joining records on the depositor and registrant CIKs in entities[], then extract fee tables, hypothetical expense examples, surrender schedules, and rider descriptions from the document layer at each filing's filedAt timestamp. Output: a dated disclosure timeline used in expert reports, damages models, and SEC examination workpapers.
Search the document files for specific clauses (voting rights, free-look terms, transfer privileges, conflicts disclosure in the SAI) across the corpus to gather drafting precedent. Use the EX-12.(K) legal opinion and EX-13.(L) accountant consent exhibits as templates. Output: redlines and comment-response packages backed by peer-disclosure citations.
Parse metadata.json across all records to assemble a reference table of separate accounts, depositor insurers, 1933 Act 333- and 1940 Act 811- file numbers, SIC codes, states of incorporation, and per-filing exhibit inventories. Output: a normalized internal master used by product analytics and data engineering teams to index the N-3 universe and link it to N-CEN, 24F-2, and N-VPFS filings.
Extract the EX-13.(L) accountant consent exhibits and EX-12.(K) legal opinions across the dataset, parse the issuing firm name from each document body, and key the result by depositor CIK and filing date. Output: a longitudinal record of auditor and outside-counsel engagements at each separate-account family, used for competitive intelligence and audit-firm conflict checks.
Index the HTML and ASCII document bodies along with documentFormatFiles[] typing as a bounded corpus for retrieval-augmented generation. Use sequence numbers and <TYPE> tags to route prospectus, SAI, and exhibit text into separate retrievers. Output: clause-level extraction and grounded answers for advisor-facing annuity comparators and disclosure-review assistants, with each citation traceable to an accession number and exhibit code.
Dataset Index JSON API: https://api.sec-api.io/datasets/form-n3-files.json
This endpoint returns the dataset metadata, including the name, description, last updated timestamp, earliest sample date, total record and size counts, covered form types (N-3, N-3/A), container format (ZIP), and included file types (TXT, JSON, HTML). It also includes the download URL for the full archive and a list of all individual container files with per-container size, record count, updated timestamp, and download URL. This endpoint does not require an API key. Use it to monitor which containers were updated in the most recent refresh run and decide which containers to download on a daily basis.
Example response:
1
{
2
"datasetId": "1f13365b-9ae0-6a32-9024-0d1e81e756e3",
3
"datasetDownloadUrl": "https://api.sec-api.io/datasets/form-n3-files.zip",
4
"name": "Form N-3 Files Dataset",
5
"updatedAt": "2026-04-16T08:35:10.043Z",
6
"earliestSampleDate": "1996-04-01",
7
"totalRecords": 296,
8
"totalSize": 11953207,
9
"formTypes": ["N-3", "N-3/A"],
10
"containerFormat": "ZIP",
11
"fileTypes": ["TXT", "JSON", "HTML"],
12
"containers": [
13
{
14
"downloadUrl": "https://api.sec-api.io/datasets/form-n3-files/2026/2026-03.zip",
15
"key": "2026/2026-03.zip",
16
"size": 13818783,
17
"records": 154,
18
"updatedAt": "2026-04-16T08:35:10.043Z"
19
}
20
]
21
}
Download Entire Dataset: https://api.sec-api.io/datasets/form-n3-files.zip?token=YOUR_API_KEY
Downloads the complete Form N-3 Files Dataset as a single ZIP archive containing all filings from April 1996 to present. This endpoint requires an API key.
Download Single Container: https://api.sec-api.io/datasets/form-n3-files/2026/2026-03.zip?token=YOUR_API_KEY
Downloads one individual monthly container archive instead of the full dataset, which is useful for incremental updates. This endpoint requires an API key.
The dataset covers Form N-3 (the original registration statement) and Form N-3/A (pre-effective and post-effective amendments). Both form types are filed by insurance company separate accounts organized as management investment companies that issue variable annuity contracts.
One record is one complete EDGAR submission of a Form N-3 or Form N-3/A, identified by its 18-digit accession number and materialized as a folder containing a metadata.json structured anchor plus one document file per item filed (prospectus, Statement of Additional Information, financial statements, and exhibits) in the original SGML-wrapped form. Image attachments are excluded by design.
Form N-3 is filed by an insurance company separate account that is registered as an investment company under the Investment Company Act of 1940, organized as a management investment company (not a unit investment trust), and issuing variable annuity contracts. The separate account is the registrant; the sponsoring life insurer (the depositor) signs the filing alongside the registrant and supplies its general account financial statements.
Both forms register variable annuity contracts issued through insurance company separate accounts. Form N-3 covers separate accounts organized as management investment companies that manage portfolios internally at the separate account level, while Form N-4 covers separate accounts organized as unit investment trusts that invest in underlying registered funds. Form N-4 dominates the modern market, which is why the Form N-3 population is small.
The dataset begins in April 1996, tracking the phase-in of mandatory EDGAR electronic filing for investment company registrants, and continues to present. The form itself was adopted in 1985, so pre-EDGAR filings are not part of this dataset.
Each record contains a JSON metadata.json file plus one or more document files carrying an SGML <DOCUMENT> envelope around either plain ASCII text (older filings, roughly April 1996 through the early 2000s) or HTML (more recent filings). The on-disk extension is typically .txt even when the inner payload is HTML, so payload-format detection should rely on content sniffing rather than the filename suffix.
Amendments are filed by the same separate account that filed the original Form N-3 and update — rather than replace — the existing registration. Amendment scope ranges from short corrective filings containing only a cover page and a single replaced exhibit to comprehensive restatements that re-file the entire registration; the formType field flags amendment status but scope must be inferred from the document inventory.