Form 40-APP Files Dataset

The Form 40-APP Files Dataset packages every Form 40-APP and Form 40-APP/A submission accepted by EDGAR — applications for orders of exemptive relief filed under the Investment Company Act of 1940 — as one record per accession number, with the structured EDGAR header captured in metadata.json and every textual exhibit preserved as HTML inside its original SGML <DOCUMENT> envelope. A single record represents one application or amendment as filed, identified by its 18-digit accession number and joined to the underlying exemptive proceeding through the 812- (and occasionally 803-) file numbers carried in each entity entry. Applications are filed by registered investment companies, business development companies, investment advisers, principal underwriters, insurance company separate accounts, UIT sponsors, and foreign investment companies — typically as joint applications listing many co-applicants under a single accession. The dataset covers filings from January 2002, when EDGAR mandatory filing for investment company applications began, through the present, and is distributed as monthly ZIP containers comprising HTML, JSON, TXT, and PDF files.

Dataset APIs

Dataset Files

What This Dataset Contains

The dataset assembles the complete applicant-side legal record of 1940 Act exemptive practice as it has accumulated on EDGAR since January 2002. Each record corresponds to one Form 40-APP or Form 40-APP/A submission as it was accepted by EDGAR, identified by its 18-digit accession number. Physically, a record is a folder named after that accession number with the dashes stripped (for example, accession 0001193125-25-300965 becomes the folder 000119312525300965). Inside that folder live a metadata.json describing the filing as a structured object and every textual document the filer attached to the original EDGAR submission. A record therefore packages two layers of evidence together: the EDGAR header data extracted into JSON, and the application package itself rendered as HTML documents that retain their original SGML <DOCUMENT> wrappers.

Form 40-APP is the EDGAR form used to submit applications for orders of exemptive relief under the Investment Company Act of 1940. It is filed pursuant to Rule 0-2 of the Commission's General Rules and Regulations. An applicant — typically a registered investment company, a business development company, an adviser, an underwriter, or a related entity — uses the form to ask the Commission, most often acting through the Division of Investment Management, to grant relief from one or more statutory or rule-based prohibitions of the Act. Common statutory anchors are Section 6(c) (general exemptive authority), Section 17(b) (relief from affiliated-transaction prohibitions in Section 17(a)), Section 17(d) and Rule 17d-1 (joint-arrangement and co-investment relief), Section 12(d)(1) (fund-of-funds relief), Section 10(f) (relief from underwriting affiliates), and Sections 18, 19, and 23 (closed-end fund repurchase, multi-class, and managed-distribution relief), among others.

The form is not a transactional disclosure document. It is a quasi-litigation pleading, drafted in legal-brief style, that combines a recitation of facts about the applicants, a precise identification of the statutory and regulatory provisions from which relief is sought, a legal and policy argument supporting the request, a set of proposed conditions under which the order would operate, and the verifications and authorizations required by Rule 0-2. The Commission's response — a notice of application and ultimately an order — is a separate proceeding and is not part of this dataset. The dataset's unit of granularity is the filing, not the application case: because the underlying SEC application proceedings (file numbers in the 812- series) often progress through an initial 40-APP filing followed by one or more 40-APP/A amendments, multiple records can map to the same 812-xxxxx case, with the relationship surfaced through shared file numbers and overlapping entities arrays rather than through any explicit parent/child link.

Content Structure of a Single Record

A record is organized into three concentric layers:

1. The accession folder itself, named by the dash-stripped accession number, which is the record's stable identifier.
2. A single metadata.json file that captures the EDGAR header for the submission: form type, filing timestamp, links back to sec.gov, the full list of filing entities with their CIKs and case file numbers, and a manifest of every attachment in the original submission.
3. The application package, consisting of one principal application document and zero or more exhibits, each preserved as an .htm file wrapped in the original SGML <DOCUMENT> envelope.

The principal application document is conventionally named with a 40app token (for example d15297d40app.htm, tema-40app_101625.htm) and carries the SGML <TYPE>40-APP tag; for amendments the convention is a 40appa token and <TYPE>40-APP/A. Exhibits follow the EDGAR exhibit-numbering convention (ex99-a1.htm, ex99-b1.htm, exhibitc-*.htm, etc.) and carry exhibit-type codes such as EX-99.(A)(1), EX-99.(B)(1), EX-99.(C)(1), EX-99.A, EX-1, and EX-2. Image attachments referenced by the original EDGAR submission (typically .jpg graphics carrying the GRAPHIC document type) are intentionally omitted from the folder; their existence is still recorded inside metadata.json -> documentFormatFiles, which preserves a faithful inventory of the original submission even though the binary image payloads themselves are not packaged.

The Accession Folder

The folder name is the canonical EDGAR accession number with dashes removed. It is the only stable join key between the dataset record and the EDGAR system of record. The corresponding hyphenated form (NNNNNNNNNN-YY-NNNNNN) appears inside metadata.json as accessionNo and inside the various sec.gov URLs.

metadata.json

metadata.json is the structured EDGAR header for the filing. Its top-level fields include:

• id — opaque internal record identifier (hex string).
• formType — either 40-APP or 40-APP/A.
• accessionNo — the hyphenated EDGAR accession number.
• description — the standard EDGAR form description, "Form 40-APP - Application for exemption and other relief filed under the Investment Company Act of 1940", with an [Amend] qualifier on amendments.
• filedAt — ISO-8601 timestamp with timezone offset reflecting Eastern time at acceptance.
• linkToFilingDetails, linkToTxt, linkToHtml — sec.gov URLs to the primary document, the EDGAR full-submission .txt, and the filing index page respectively.
• linkToXbrl — present for schema parity with other EDGAR datasets; 40-APP filings do not carry XBRL data and this field is empty.
• documentFormatFiles — an array describing every attachment in the original submission. Each entry carries sequence (numeric ordinal within the submission, with a single space " " reserved for the complete-submission .txt), documentUrl, filer-supplied description, EDGAR type code (such as 40-APP, 40-APP/A, EX-99.(A)(1), EX-99.A, EX-1, GRAPHIC), and size in bytes (string-encoded). The manifest enumerates files that exist on EDGAR even when, as with images, they are not packaged on disk in the dataset.
• entities — an array of every entity associated with the filing. A 40-APP commonly carries many co-filers because exemptive orders are sought by, and granted to, broad groups of related funds, advisers, underwriters, and trustees; complex applications routinely list dozens of entities. Each entity entry includes cik, companyName (with role suffix such as (Filer)), the entity-specific type (40-APP / 40-APP/A), fileNo (often the application case number 812-xxxxx, sometimes also 803-xxxxx for adviser file numbers), filmNo (the EDGAR-assigned acceptance identifier), stateOfIncorporation (two-letter state or province code), act (98 denotes the Investment Company Act of 1940), irsNo (000000000 when not supplied), and fiscalYearEnd in MMDD form.
• seriesAndClassesContractsInformation — present but typically empty for 40-APP filings.
• dataFiles — present but typically empty, since 40-APP filings do not carry data attachments.

The Principal Application Document

The principal .htm document is the substantive application. It opens with a Rule 0-2 cover statement identifying the applicants, the file number, and the provisions of the Act involved, and is then organized into named sections that, while not formally enumerated by the form, follow a stable convention developed by the Division of Investment Management:

• Summary of Application — a short paragraph naming the applicants and stating, in plain terms, the order requested and the provisions of the Act involved.
• Applicants — identification of every applicant, including organizational form, jurisdiction of organization, regulatory status under the Act (registered open-end fund, closed-end fund, BDC, adviser registered under the Investment Advisers Act of 1940, broker-dealer registered under the Exchange Act, etc.), and how they relate to one another.
• Background and Description of Proposed Transactions or Arrangements — the factual recitation of what the applicants want to do and why existing rules constrain them. For multi-class or fund-of-funds relief this typically describes share-class structures, distribution arrangements, master-feeder relationships, or affiliated investments.
• Requested Order / Relief Requested — a precise statement, section by section and rule by rule, of the exemptions requested. Applications routinely cite Sections 6(c), Section 12(d)(1)(J), 17(b), 17(d), Section 19(b), Section 23(c), and others, paired with specific rules (Rule 17d-1, Rule 12d1-4, Rule 22e-3, Rule 23c-3, Rule 19b-1, etc.).
• Legal Analysis — the argument that the requested relief is necessary or appropriate in the public interest and consistent with the protection of investors and the purposes of the Act, the standard articulated in Section 6(c). This section frequently cites and distinguishes prior orders granting comparable relief.
• Conditions — a numbered list of conditions, often modeled on conditions imposed in prior orders, that the applicants accept as binding if the order is granted. Conditions are operationally important because they become the enforceable terms of the eventual exemptive order.
• Procedural Matters — Rule 0-2(c) statements naming the persons authorized to receive Commission communications, the address for notice, and a reservation of the right to amend.
• Signatures and Authorizations — signature blocks for each applicant, typically referencing the authorizing resolutions filed as exhibits.

Section headings vary in wording across filers and outside counsel, but the ordering and substantive content above are stable across the dataset.

Exhibits

Exhibits implement the formal requirements of Rule 0-2 and any applicant-specific evidentiary needs. Common exhibit families include:

• Authorizations (EX-99.(A)(1), EX-99.(A)(2), etc.) — board resolutions or comparable instruments authorizing the filing. Rule 0-2(c)(1) requires that an application by a corporation, partnership, or other entity be authorized by an appropriate resolution.
• Verifications (EX-99.(B)(1), EX-99.(B)(2), EX-99.A, etc.) — sworn or affirmed statements by an authorized officer that the facts stated in the application are true to the best of the signer's knowledge, satisfying Rule 0-2(d).
• Marked copies (EX-99.(C)(1), EX-99.(C)(2), etc.) — for amendments, blacklined or otherwise marked versions of the application showing changes from the prior version.
• Substantive exhibits (EX-1, EX-2, and ad-hoc EX-99 sub-letters) — supporting documents such as side letters, fee schedules, investment guidelines, sub-adviser agreements, or counterparty confirmations relevant to the relief requested.

Each exhibit, like the principal document, is preserved as an .htm file wrapped in the original SGML <DOCUMENT> envelope. Exhibit sequencing inside documentFormatFiles matches the order in which the filer submitted the parts to EDGAR.

SGML Document Wrapper

Every .htm payload retains the original EDGAR <DOCUMENT> envelope used inside the full-submission .txt. The wrapper exposes, in plain text before the <TEXT> block, the document <TYPE> (e.g., 40-APP, EX-99.(A)(1)), <SEQUENCE> ordinal, <FILENAME>, and <DESCRIPTION> fields, followed by the HTML body inside <TEXT>...</TEXT>. These header fields mirror the corresponding entry in metadata.json -> documentFormatFiles and provide a redundant, self-describing header that does not require parsing the JSON to identify the role of a given document.

What the Record Includes

A record reliably includes:

• The accession folder identified by the dash-stripped accession number.
• The metadata.json header, with the full list of co-filing entities, their CIKs and 812- / 803- file numbers, the filing timestamp, and the original-submission attachment manifest.
• The principal 40-APP or 40-APP/A application document as HTML inside its SGML wrapper.
• All textual exhibits attached to the original EDGAR submission — authorizations, verifications, marked copies, and any substantive supporting documents — each as an HTML document inside its SGML wrapper.

What the Record Excludes

A record deliberately excludes binary image attachments (typically .jpg files carrying the GRAPHIC document type in EDGAR), even when they are part of the original submission. Their presence is still recorded in documentFormatFiles, so the manifest remains a faithful inventory of the original EDGAR submission, but the image payloads themselves are not stored on disk.

A record also does not contain Commission-side artifacts: the staff's notice of application, any deficiency or comment correspondence, the final exemptive order, or any related Federal Register publications. Those are separate proceedings published outside the 40-APP form. Likewise, where an application has been amended, the amendments appear as their own records (form type 40-APP/A, distinct accession numbers) rather than as supplements to the original record; the relationship is recoverable through shared 812- file numbers in the entities array.

Changes in Required Content and Structure Over Time

Form 40-APP was introduced as part of the EDGAR mandatory-filing rules for investment-company applications adopted in 2001 and was used for filings beginning in 2002, which sets the lower bound of the dataset's coverage at January 2002. Before that, exemptive applications were submitted in paper form and are outside the scope of this dataset.

Although the form itself has remained essentially a pleading shell governed by Rule 0-2, the substantive content of applications has shifted with the underlying regulatory landscape. Notable inflection points include:

• The 2003 multi-class relief framework for closed-end funds, which generated a recurring pattern of Section 18 / Section 23 / Rule 19b-1 conditions visible in the Conditions sections of closed-end fund applications.
• The 2006-2019 ETF exemptive-order era and the long line of individual ETF orders that preceded Rule 6c-11; these applications carried highly conventionalized sections on creation/redemption, secondary-market trading, and Section 17(a) relief for affiliated authorized participants. The adoption of Rule 6c-11 in 2019 sharply reduced the volume of plain-vanilla ETF 40-APP filings, shifting the population toward non-transparent active ETFs, multi-class structures, and other matters not covered by the rule.
• The 2020 fund-of-funds rulemaking that produced Rule 12d1-4, which similarly compressed the historical population of Section 12(d)(1) applications and shifted the residual population toward bespoke arrangements outside the rule's safe harbor.
• The expanded use of joint-conduct relief under Section 17(d) and Rule 17d-1 in connection with co-investment programs by BDCs and registered closed-end funds, which produced the now-standard "co-investment order" template visible across many records.

These shifts do not change the structural anatomy of a 40-APP record — the form's sections, its Rule 0-2 cover statements, and its exhibit conventions remain stable — but they do change which statutory provisions are cited in Requested Order and which condition templates appear in Conditions.

Changes in Data Format Over Time

EDGAR adoption for 40-APP coincided with the move to HTML-based filings, so the dataset's .htm documents are uniformly HTML wrapped in the SGML <DOCUMENT> envelope across the full 2002-to-present range. There is no ASCII-only era for this form within the dataset's coverage. The most visible format evolution within the dataset is presentational rather than structural: earlier filings tend toward minimal HTML approximating typewritten legal pleadings, while later filings increasingly use richer HTML styling, embedded tables, and (where permitted) inline graphics. The exhibit-naming and exhibit-type vocabulary has remained consistent, anchored to the Rule 0-2 categories of authorizations and verifications.

The file-types found in the dataset are HTML, JSON, TXT, and PDF. In practice, a record consists almost entirely of .htm documents plus the per-record metadata.json; PDF and TXT payloads appear only where a filer chose those formats for individual exhibits or where the original submission included them, and image attachments are excluded as described above.

Interpretation Notes

Several nuances matter when working with these records:

• Amendments are independent records. A 40-APP/A is a separate accession with its own folder, its own metadata.json, and its own SGML-wrapped HTML documents. Reconstructing the full life of an application requires grouping records by the fileNo value (typically 812-xxxxx) inside each entity entry, since the accession number alone does not encode that linkage.
• Co-filer cardinality is high. A single 40-APP commonly carries many entities in its entities array — sometimes dozens, when an application is filed on behalf of an entire fund complex. Each entity carries its own CIK and fileNo, and the same physical metadata.json will list all of them. Treating the record as belonging to a single CIK will under-represent the population of affected entities.
• The manifest is canonical, the folder is curated. documentFormatFiles lists every attachment in the original EDGAR submission, including images that are not stored on disk. Reconciling the two views is straightforward: any entry with type GRAPHIC (or other image-typed entries) will be present in the manifest but absent from the folder.
• SGML headers are reliable extraction anchors. Because every .htm retains its original <DOCUMENT> wrapper with <TYPE>, <SEQUENCE>, <FILENAME>, and <DESCRIPTION> fields, the role of any given file (principal application, authorization, verification, marked copy, substantive exhibit) can be determined without parsing the HTML body and without consulting the JSON manifest, providing useful redundancy when one of the two layers is malformed.
• Application content is legal prose, not transactional disclosure. Extraction strategies tuned for periodic-report Items will not transfer cleanly. The substantive structure to target is the Rule 0-2 cover, the Summary of Application, the Applicants section, the Requested Order, the Legal Analysis, the numbered Conditions, the Rule 0-2(c) procedural statement, and the signature/authorization blocks, recognizing that section headings vary in wording across filers but follow the conventions described above.
• File numbers are the most stable cross-record key. The 812-xxxxx (and occasionally 803-xxxxx) values inside entities[*].fileNo are the durable identifiers of an exemptive proceeding and are the right join key for assembling an application's full filing history, including original submission, amendments, and any related applications by the same applicant group.
• Role suffixes in companyName are informative. The parenthetical role qualifier ((Filer), occasionally other roles) attached to each entity name distinguishes the filing entity from co-applicants and should be stripped before name-based matching against external registries.

Who Files or Publishes This Dataset, and When

Each record is a single application to the SEC for an exemptive, declaratory, or other discretionary order under the Investment Company Act of 1940. The filer is an applicant asking the Commission to permit conduct that a section of the Act, or a rule under it, would otherwise restrict. Applicants are not ordinary operating-company registrants. They typically include:

• Registered investment companies — open-end funds, closed-end funds, ETFs, and unit investment trusts registered on Form N-1A, Form N-2, or Form N-8B-2.
• Business development companies (BDCs), often seeking co-investment, multi-class, or capital-structure relief.
• Investment advisers and sub-advisers registered under the Advisers Act, joined when the relief contemplates adviser conduct (manager-of-managers, affiliated transactions, multi-manager structures).
• Principal underwriters and distributors of fund shares.
• Affiliated persons within the fund complex (parent holding companies, affiliated funds, separate accounts) that need the order to cover their conduct.
• Insurance company separate accounts registered as UITs or management companies, often seeking fund substitution or mixed-and-shared funding relief.
• UIT sponsors and trustees, including legacy ETF sponsors that needed relief before Rule 6c-11.
• Foreign investment companies and their affiliates seeking permission for a U.S. public offering under Section 7(d).

Applications are almost always joint: a single 40-APP lists multiple related applicants so the resulting order covers each of them. EDGAR shows one CIK as the filer of record (often a lead fund, the adviser, or a representative entity), but the body of the application names every applicant. A Form 40-APP/A is an amendment to a pending 40-APP filed by the same applicants to revise factual representations, legal arguments, proposed conditions, requested scope, or the applicant list.

When the Record Is Triggered

Form 40-APP is event-driven, not periodic. There is no statutory deadline. A filing arises whenever an investment company or related person wants to engage in conduct restricted by the Act and cannot rely on an existing rule or class exemption. Procedurally, the filing is governed by:

• Rule 0-2 under the Act — format, verification, signature, and authorization for applications.
• Rule 0-5 — Commission consideration, notice, and hearing procedures.
• The substantive section under which relief is requested. The most common is Section 6(c) (general exemptive authority). Other frequent bases include Section 17(b) and Rule 17d-1 (affiliated and joint transactions), Section 10(f) (purchases from affiliated underwriters), Section 12(d)(1)(J) (fund-of-funds), Section 23(c)(3) (closed-end repurchases), and Section 18(c), Section 18(f), and Section 18(i) (capital structure and senior securities).

A 40-APP is filed once the applicants (typically through outside counsel) have prepared a complete written application identifying the applicants, the requested order, the legal authority, the relevant facts, the legal analysis, the proposed conditions, and the Rule 0-2 verifications. It is submitted to EDGAR as form type 40-APP, usually well in advance of the contemplated activity, because staff review and the notice-and-order process commonly take many months. A 40-APP/A is generated whenever applicants amend a pending application — most often in response to comment letters from the Division of Investment Management staff. Multiple amendments per application are common; they have no fixed cadence and follow the comment-and-response cycle. The application is effectively complete only when the Commission issues an order, which is published as a separate Commission release rather than as a 40-APP filing.

Earliest Records

Exemptive applications have existed since the Act took effect on August 22, 1940, but were filed in paper for the first six decades. The 40-APP EDGAR submission type was introduced when electronic filing for investment company applications was mandated; the earliest 40-APP filings on EDGAR appear in January 2002, the start of this dataset's coverage.

Important Distinctions

• Applicant vs. registrant. Co-applicants (especially advisers) are not necessarily EDGAR periodic filers. They appear on the 40-APP because the order will authorize their conduct, not because they have an independent reporting obligation.
• 40-APP vs. adjacent application form types. Use 40-APP for substantive exemptive relief under Section 6(c) and related provisions. Other EDGAR types serve procedurally distinct categories: Form 40-OIP (other initial proceedings), Form 40-6B (Section 6(b) employees' securities companies), and Form 40-8F-2 (declarations under Section 8(f) that a registered investment company has ceased to be one).
• 40-APP vs. no-action letters. A 40-APP seeks a binding Commission order. Staff no-action letters address whether the staff would recommend enforcement and are not filed on EDGAR through this form.
• 40-APP vs. rule-based exemptions. Activities once requiring individual orders may now be permitted by general rules — ETF operation under Rule 6c-11, fund-of-funds under Rule 12d1-4, certain affiliated transactions under Rule 17a-7. Once a rule is in force, the corresponding 40-APP traffic falls off, which is why the subject mix shifts over time.
• Amendments. A 40-APP/A continues prosecution of an existing application; it does not reset the procedural posture or start a new matter. Reconstructing the requested relief requires reading the original together with each amendment.
• Withdrawals. Withdrawn applications are filed under different EDGAR submission types and are not part of the 40-APP / 40-APP/A population.
• Foreign private issuers. Foreign operating companies use the Exchange Act regime (20-F, 40-F, 6-K), not 40-APP. Foreign investment companies seeking Section 7(d) relief, however, are exactly the kind of applicant that uses 40-APP.

How This Dataset Differs From Similar Datasets or Filings

Form 40-APP's closest neighbors are other 1940 Act application vehicles, the registration and periodic forms filed by the same investment-company population, and the SEC-side documents that dispose of the application. Operating-company forms (10-K, 10-Q, 8-K) and beneficial-ownership filings (13D/G, 13F, Forms 3/4/5) are not meaningful comparisons and are noted only at the end as non-substitutes.

Form 40-APP/A (Amendment to 40-APP)

Included inside this dataset as the second formType. A 40-APP/A is the same legal vehicle as the underlying 40-APP, shares the same 812- file number, and typically responds to staff comments, narrows requested relief, revises proposed conditions, or adds applicants. It is a continuation record, not a separate filing type: the operative legal text is usually only complete when a 40-APP is read together with its amendments in sequence, keyed by file number.

Form 40-OIP and 40-OIPC (Notice of Order / Conditional Order)

The Commission's response side of the same exemptive workflow. They share the 812- file number and reference the underlying application by name. The split is authorship and content: 40-APP is filed by the applicant and contains the full factual record, legal argument, and proposed conditions; 40-OIP/40-OIPC are drafted by SEC staff and contain a condensed summary plus the formal grant. Use 40-OIP/40-OIPC for outcomes; use 40-APP for what was requested and how it was argued.

Form 40-6B (1940 Act Applications by BDCs)

Same statutory foundation (Rule 0-2, Sections 6(c), 17, 12, 23) and the same exhibit conventions (Rule 0-2(d) verifications, board authorizations). The distinction is filer population: 40-6B is the application vehicle for business development companies, while 40-APP is the general-purpose application used by registered investment companies, advisers, and ETF sponsors. A complete view of 1940 Act exemptive practice requires both, but 40-APP is the broader and more frequently used form.

Form ADV and the 803- File-Number Track

Form ADV is the Investment Advisers Act registration/disclosure form for the adviser entity itself — structured, periodic, and filer-centric. 40-APP is episodic and transaction-centric: a one-off legal petition that may name an adviser as a co-applicant. The overlap is the population (many 40-APP applicants are advisers) and the occasional 803- file number that appears on a 40-APP, signaling the same application is being pursued in parallel under the Advisers Act. ADV will not show what relief was sought; 40-APP will not show the adviser's AUM, ownership, or disciplinary history.

Form N-1A, N-2, N-3, N-4, N-6, N-8B-2 (1940 Act Registration Statements)

Same filer universe (open-end funds, closed-end funds, variable-annuity separate accounts, UITs) and same statute, but opposite purpose: registration statements create an offering and disclose the fund's investment program, fees, and risks to investors. They are voluminous, periodic, and prospectus-shaped. 40-APP is episodic, legal, and argumentative — it asks the Commission to waive a specific provision for a defined transaction structure. A fund family may file dozens of N-1A post-effective amendments per year and only occasionally file a 40-APP. (Form N-3, Form N-4, and Form N-6 cover variable contract registration statements.)

Form N-CEN and Form N-PORT (Periodic Fund Reporting)

Highly structured XML/XBRL datasets covering annual census data (N-CEN) and monthly portfolio holdings (N-PORT) for the same investment-company population. They are the operational and tabular complement to 40-APP's free-text legal prose. N-CEN/N-PORT will not reveal whether a fund operates under exemptive relief; 40-APP will not show portfolio composition or expenses. They are complements, not substitutes.

UPLOAD and CORRESP (Staff Correspondence)

The UPLOAD/CORRESP correspondence stream and Division of Investment Management no-action letters cover overlapping subject matter — 1940 Act questions discussed with staff — but are procedurally distinct. A 40-APP seeks a Commission-level exemptive order (broader and more durable); a no-action request seeks a staff non-enforcement position. Correspondence with staff during a 40-APP's pendency lives in CORRESP filings under the same 812- file number and is not part of this dataset.

Form 40-F (Disambiguation Only)

Despite the similar form-number prefix, Form 40-F is an Exchange Act annual report filed by Canadian issuers under the Multijurisdictional Disclosure System. It has no statutory, content, or filer-population overlap with Form 40-APP. Listed only because substring searches on "40-" can conflate the two.

Key Differences at a Glance

• Direction of the document: 40-APP is applicant-to-Commission (request); 40-OIP/40-OIPC is Commission-to-public (disposition); N-1A/N-2 is fund-to-investor (offering); N-CEN/N-PORT is fund-to-Commission (periodic reporting); ADV is adviser-to-Commission (registration).
• Cadence: 40-APP is episodic and transaction-driven; registration and periodic forms are scheduled and recurring.
• Shape of payload: 40-APP is unstructured HTML legal prose with EX-99 verifications and authorizations attached, no XBRL, image exhibits excluded. N-CEN/N-PORT/ADV are structured tabular data; N-1A/N-2 are prospectus narrative plus tagged financial data.
• Filer cardinality: 40-APP routinely has many co-applicants under one accession (the Fidelity sample carries 33 entities); registration and periodic forms are typically one filer per accession.
• File-number family: 40-APP uses 812- (and sometimes 803-); registration statements use 811-/333-; ADV uses 801-/802-.

Boundary Summary

Form 40-APP is the only EDGAR dataset that captures the full applicant-side legal record of 1940 Act exemptive practice — the petition itself, the proposed conditions, the Rule 0-2(d) verifications, and the board authorizations — in one place, keyed to an 812- (or 803-) case number that links forward to a 40-OIP/40-OIPC order and sideways to the registration and periodic filings of the same funds. Its closest neighbors (40-APP/A, 40-OIP, 40-6B) sit inside the same exemptive workflow; its filer-population neighbors (N-1A/N-2, N-CEN/N-PORT, ADV) describe the same entities for entirely different purposes. It is not interchangeable with any of them, and it has no relationship to operating-company periodic forms, beneficial-ownership filings, or Form 40-F.

Who Uses This Dataset

Form 40-APP filings record the legal reasoning, statutory citations, and negotiated conditions behind exemptive relief under the Investment Company Act of 1940. The dataset serves a narrow professional audience built around drafting, complying with, and analyzing those orders.

Investment Management Lawyers and Fund Counsel

In-house and outside counsel advising registered funds, BDCs, and their advisers use prior 40-APPs as the primary precedent base for new applications. They mine recitals, the specific 1940 Act sections cited (6(c), 17(b), 17(d), 12(d)(1), 57), and especially the proposed conditions of relief, comparing condition language word for word to predict how the staff will receive a new request and to draft around known objections.

Fund Compliance and Regulatory Affairs Officers

CCOs and regulatory staff at fund sponsors and ETF issuers treat granted conditions as enforceable obligations. They use the dataset to build condition checklists, map ongoing reporting and recordkeeping duties, and confirm that internal policies, board reporting, and trading workflows match what was represented to the Commission.

Product Development and Fund Structuring Teams

Teams designing multi-manager arrangements, ETF share class overlays, interfund lending facilities, co-investment programs, and cross-trading structures use the dataset as a feasibility map. They focus on the description of proposed transactions, the relief requested, and the conditions imposed to identify which structures the staff has already authorized and on what terms.

BDC and Private Credit Counsel

Counsel and compliance staff at BDCs depend on co-investment and affiliated transaction relief. They study Section 17(d), Rule 17d-1, and Section 57 applications for accepted allocation methodologies, follow-on and disposition mechanics, and the board oversight conditions required to operate the program.

ETF and Closed-End Fund Sponsors

Sponsors launching active, semi-transparent, or novel ETF structures benchmark the relief they need against precedent applications. They focus on creation and redemption mechanics, in-kind transaction relief, and conditions governing portfolio transparency and arbitrage to draft their own applications and price the regulatory timeline into launch plans.

Fund Boards and Independent Trustee Counsel

Independent directors and their counsel use the dataset to understand the limits of the orders their funds operate under, especially when approving co-investment, affiliated, or fund-of-funds transactions. They focus on conditions that require board findings, periodic board reporting, or independent director approval.

Internal and External Auditors

Audit teams testing whether a complex operates consistently with its exemptive orders compare actual practice against the conditions and representations on file. They use the application text to scope tests, identify potential breaches, and support compliance findings.

Securities Regulatory Researchers

Academic and policy researchers use the dataset as a longitudinal record from 2002 forward. They aggregate by statutory section, applicant type, and relief category to track shifts in staff positions, condition standardization, and amendment activity, supporting comment letters, rulemaking analyses, and academic work.

Legal Tech and Regulatory Data Engineers

Engineering teams at legal technology vendors, asset managers, and regulatory analytics providers ingest the dataset to build searchable precedent libraries. They rely on the metadata, HTML and TXT bodies, and accession-number structure to classify applications by statutory section and extract applicants, requested relief, and conditions as structured fields. Adjacent SEC-API datasets such as Form 10-K, Form 10-Q, Form 8-K, Form N-1A, Form N-CEN, Form N-PORT, Form 20-F, Form 40-F, Form 6-K, and Form ADV give engineers the parallel periodic and registration corpora needed to align 40-APP applicants with their broader filing footprints.

LLM and RAG Developers

Teams building retrieval-augmented systems for investment management law use the corpus to train and evaluate models that summarize relief, surface precedent, draft application sections, and answer questions about specific conditions. The consistent legal vocabulary and the 40-APP/A amendment history make it a high-signal domain corpus.

Specific Use Cases

The dataset supports a small set of concrete workflows that all draw on the same legal record: applicants, statutory citations, requested relief, and proposed conditions.

• Drafting a new exemptive application from precedent. Fund counsel preparing a Section 17(d) co-investment, Section 12(d)(1) fund-of-funds, or Section 6(c) ETF application pull the principal 40-APP HTML documents from prior records granted to comparable applicants, diff their Requested Order and Conditions sections against the current draft, and reuse condition language that the staff has already accepted. Records are grouped by 812- file number to read the original together with each 40-APP/A amendment in sequence.

• Building a condition-compliance checklist for a fund complex. CCOs extract the numbered Conditions sections from every 40-APP and 40-APP/A whose entities[*].cik matches their complex, then map each condition to internal policies, board reporting cadences, and recordkeeping owners. The Rule 0-2(d) verifications and board authorizations in the EX-99.(A) and EX-99.(B) exhibits anchor what was represented to the Commission.

• Mapping a fund family's exemptive footprint. Researchers and legal-tech teams join records across the dataset on entities[*].fileNo (812-xxxxx and 803-xxxxx) and CIK to assemble, per applicant group, the full set of orders relied upon, including originals and all amendments. The output is a per-complex inventory of statutory sections invoked and conditions accepted, useful for diligence, M&A integration, and audit scoping.

• Tracking shifts in staff positions over time. Policy researchers aggregate records by year, statutory anchor (Section 19, Section 6(c), 17(b), 17(d), 12(d)(1), 18, 23), and applicant type to chart how condition templates evolved around inflection points such as Rule 6c-11 (2019) and Rule 12d1-4 (2020). The HTML payloads and stable section conventions make this a longitudinal corpus from January 2002 forward.

• Powering retrieval-augmented question answering on 1940 Act relief. LLM teams chunk the principal application documents along the standard sections (Summary of Application, Applicants, Requested Order, Legal Analysis, Conditions) using the SGML <TYPE> and <DESCRIPTION> headers as routing signals, and index entities, fileNo, and formType from metadata.json as filters. The result supports queries like "show me co-investment orders with follow-on conditions for non-traded BDCs."

• Co-applicant network and counsel-market analysis. Because a single 40-APP commonly lists dozens of co-filing entities, analysts iterate the entities array across all records to build applicant co-occurrence graphs (fund / adviser / underwriter / trustee), identify which sponsors cluster around shared advisers, and rank outside counsel activity by parsing signature blocks and Rule 0-2(c) procedural statements in the principal document.

• Auditing operations against representations on file. Internal and external auditors use the Background and Description of Proposed Transactions and Conditions sections to scope test programs, then compare current allocation methodologies, board approvals, and disclosure practices against the specific representations made when the order was sought, citing exhibits and accession numbers as workpaper evidence.

Dataset Access

The Form 40-APP Files Dataset is available through three access methods: a dataset index JSON API for metadata and container listings, a full dataset archive download, and individual container file downloads.

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

This endpoint returns dataset-level metadata (name, description, last updated timestamp, earliest sample date, total records, total size, form types covered, container format, and file types), the full dataset download URL, and a list of all container files with per-container metadata such as size, record count, last updated timestamp, and download URL. Use this endpoint to monitor which containers have been updated in the most recent refresh run and to decide which containers to download incrementally on a daily basis. This endpoint does not require an API key.

Example response:

          1
          {
        

          2
            "datasetId": "1f13365b-9ae0-68f1-b7c5-661aacac9ebc",
        

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

          4
            "name": "Form 40-APP Files Dataset",
        

          5
            "updatedAt": "2026-04-25T02:57:11.381Z",
        

          6
            "earliestSampleDate": "2002-01-01",
        

          7
            "totalRecords": 6390,
        

          8
            "totalSize": 539174885,
        

          9
            "formTypes": ["40-APP", "40-APP/A"],
        

          10
            "containerFormat": "ZIP",
        

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

          12
            "containers": [
        

          13
              {
        

          14
                "downloadUrl": "https://api.sec-api.io/datasets/form-40app-files/2026/2026-04.zip",
        

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

          16
                "size": 13818783,
        

          17
                "records": 154,
        

          18
                "updatedAt": "2026-04-25T02:57:11.381Z"
        

          19
              }
        

          20
            ]
        

          21
          }
        

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

Downloads the complete dataset as a single ZIP archive containing all monthly containers from January 2002 to the present. This endpoint requires an API key.

Download Single Container: https://api.sec-api.io/datasets/form-40app-files/2026/2026-04.zip?token=YOUR_API_KEY

Downloads one individual monthly container ZIP, which is useful for incremental updates or when only a specific time window is needed. This endpoint requires an API key.

Frequently Asked Questions

What forms does this dataset cover?

The dataset covers Form 40-APP, the EDGAR submission used to apply for orders of exemptive relief under the Investment Company Act of 1940, and Form 40-APP/A, the amendment vehicle filed by the same applicants to revise a pending application. Both form types are included as records under the same accession-folder structure.

What does one record in this dataset represent?

One record corresponds to a single Form 40-APP or Form 40-APP/A submission as accepted by EDGAR, identified by its 18-digit accession number. The record is a folder containing a metadata.json EDGAR header and every textual document attached to the original submission — the principal application document and its exhibits — each preserved as HTML inside its original SGML <DOCUMENT> envelope.

Who is required to file Form 40-APP?

Form 40-APP is filed by applicants seeking a Commission order under the Investment Company Act of 1940 — typically registered investment companies, business development companies, investment advisers, principal underwriters, insurance company separate accounts, UIT sponsors, and foreign investment companies seeking Section 7(d) relief. Applications are almost always joint, with one CIK shown as the EDGAR filer of record and many co-applicants named in the body and entities array.

When are 40-APP records filed?

Form 40-APP is event-driven, not periodic, with no statutory deadline. A filing arises whenever an investment company or related person wants to engage in conduct restricted by the Act and cannot rely on an existing rule or class exemption. A 40-APP/A is generated whenever applicants amend a pending application, most often in response to comment letters from Division of Investment Management staff.

What time period does the dataset cover?

The dataset begins in January 2002, which is when EDGAR mandatory electronic filing for investment company applications took effect, and runs through the present. Earlier paper-filed exemptive applications predating EDGAR adoption are outside the scope of the dataset.

What file format is the dataset distributed in?

The dataset is distributed as monthly ZIP containers; the file types found inside are HTML, JSON, TXT, and PDF. Each record folder consists almost entirely of .htm documents wrapped in SGML <DOCUMENT> envelopes plus a per-record metadata.json, with binary image attachments (typically .jpg GRAPHIC files) deliberately excluded even though their existence is preserved in the documentFormatFiles manifest.

How does this dataset differ from Form 40-OIP / 40-OIPC?

Form 40-APP is the applicant-side filing — the petition, the legal argument, the proposed conditions, the Rule 0-2(d) verifications, and the board authorizations. Forms 40-OIP and Form 40-OIPC are the Commission-side disposition documents (the notice of application and the order) drafted by SEC staff under the same 812- file number. Use 40-APP for what was requested and how it was argued; use 40-OIP/40-OIPC for the outcome.

How are originals and amendments linked together?

Amendments are independent records: each 40-APP/A has its own accession number, its own folder, and its own metadata.json. The durable join key for assembling an application's full life cycle is the 812-xxxxx (and occasionally 803-xxxxx) value carried inside entities[*].fileNo, since the accession number alone does not encode the parent/child relationship.