The Form APP ORDR Files dataset is the EDGAR-archived collection of orders issued by the U.S. Securities and Exchange Commission disposing of applications for exemptive relief — almost exclusively under the Investment Company Act of 1940. Each record is one accession-numbered Commission order, the dispositive instrument that grants or conditionally grants relief sought by an applicant on a 812-NNNNN application docket. The Commission itself is the EDGAR filer of record, posting orders on the applicants' behalf through the Division of Investment Management under delegated authority. Coverage runs from January 2009 forward, with monthly ZIP containers each holding the order PDFs and a normalized metadata.json per accession, distributed in the dataset's PDF + JSON file mix.
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:
A single dataset record is one EDGAR submission of form type APP ORDR — a Commission-issued order disposing of an application for exemptive relief, almost always under the Investment Company Act of 1940. The record unit is the accession, materialised on disk as one accession-numbered subdirectory, not the PDF and not the underlying application docket. A single application docket (file number 812-NNNNN) typically generates several EDGAR submissions over its lifecycle — the application (40-APP), any amendments (40-APP/A), the public notice, and finally the order — but only the dispositive order is in scope here.
The dataset captures every APP ORDR submission accepted by EDGAR from January 2009 to the present, packaged as monthly ZIP containers and refreshed on a rolling basis. Each accession folder bundles the order PDF and a normalized JSON summary; image files are excluded by dataset policy. Earlier Commission orders predating January 2009 exist in Commission release archives but are not part of the APP ORDR EDGAR collection, and routine no-action letters, interpretive releases, and rulemaking orders are issued through different channels and do not appear under this form type.
The dataset is delivered as one ZIP per calendar month, keyed form-app-ordr-files/<YYYY>/<YYYY>-MM.zip. Decompression yields a single top-level folder named after the month (e.g. 2025-12/); every immediate child of that folder is one accession directory, and there is no monthly manifest, index, or sidecar. Accession folder names are the 18-digit EDGAR accession number with the dashes stripped (e.g. 999999999725003915 for accession 9999999997-25-003915). Inside each accession folder the file set is uniform: a metadata.json summary and the order PDF, conventionally named filename1.pdf (typically 75–100 KB, two pages). Image files are excluded by dataset policy. When an APP ORDR submission carries additional documents they would appear as further sequenced PDFs (filename2.pdf, …), but the order is normally a self-contained two-page document. The complete-submission SGML wrapper that EDGAR generates is not bundled — only its URL is exposed via metadata.json (linkToTxt).
A structural quirk: the filer-of-record CIK encoded in the accession number is the EDGAR staff sentinel 9999999997, used when the Commission posts orders on the applicants' behalf. The applicant's own CIK appears inside metadata.json (in entities[0].cik and in the EDGAR URLs under /data/<applicantCIK>/), not in the folder name. This inverts the issuer-filed convention where the folder-name CIK identifies the registrant.
metadata.json contentmetadata.json is a small (~1.5 KB) normalised JSON object summarising the submission. It carries: formType (always the literal "APP ORDR"); accessionNo in dashed form; linkToFilingDetails (URL of the order PDF); linkToHtml (the EDGAR filing-index page); linkToTxt (URL of the SGML submission wrapper); description, a free-text label of the form Form APP ORDR - 40-APP Order - Item YYYYMMDD that may carry multiple Item YYYYMMDD tokens encoding the order date and prior notice or application milestones; filedAt, an ISO-8601 timestamp with the EDGAR Eastern-time offset; documentFormatFiles, an array containing the PDF order (type: "APP ORDR", sequence: "1") plus a complete-submission text-file entry, each with size and documentUrl; entities, an array of submission entities each carrying companyName (with an EDGAR role suffix such as (Filer)), cik, fileNo (the 812-NNNNN application docket), irsNo, act (always "98" for the 1940 Act), type, filmNo, and optional fiscalYearEnd, stateOfIncorporation, and tickers; id, a 32-character content hash; and items, an array mirroring the EDGAR ITEMS header lines. The fields seriesAndClassesContractsInformation, dataFiles, and linkToXbrl are present but empty for APP ORDR records. entities is typically length 1 even when the order names many co-applicants; the additional applicants are recoverable only from the PDF caption.
The PDF is the substantive record. Its structure is highly templated and follows a fixed sequence:
UNITED STATES OF AMERICA / BEFORE THE / SECURITIES AND EXCHANGE COMMISSION.INVESTMENT COMPANY ACT OF 1940, Release No. <NNNNN> (currently in the 35000s), and the release date.In the Matter of: followed by a list of applicant entity names (one to a dozen lines), the principal office address, and the application docket (812-NNNNN).ORDER UNDER SECTION 6(c)…GRANTING AN EXEMPTION FROM SECTION 15(a) for manager-of-managers relief, or ORDER UNDER SECTIONS 17(d) AND 57(i)…AND RULE 17d-1 for BDC/closed-end co-investment relief.IT IS ORDERED clause granting relief "effective immediately, subject to the conditions contained in the application, as amended."For the Commission, by the Division of Investment Management, under delegated authority.The order does not restate the substantive conditions of the relief. Conditions — frequently dozens of numbered paragraphs governing valuation, board oversight, allocation, recordkeeping, and reporting — live in the underlying 40-APP application and are incorporated by reference. Reconstructing the full regulatory bargain therefore requires the application docket, which is a separate EDGAR submission outside this dataset. No exhibits are typically attached to the order itself.
Each order is the terminal event in a typical sequence: a 40-APP application is filed, optionally amended (40-APP/A), noticed via a public Investment Company Act release, and — absent a hearing request — granted by the APP ORDR order, which cites the prior notice release and incorporates the application's conditions. The notice release number printed in the PDF and the earlier Item YYYYMMDD tokens in description/items are the most reliable cross-references back to upstream filings on the same 812-NNNNN docket.
The structural skeleton of the order — caption, action title, recitals, findings, ordered clause, delegated-authority line, Assistant Secretary signature — has been stable across the dataset's 2009–present coverage and predates EDGAR. Content has shifted rather than structure: BDC co-investment relief under sections 17(d)/57(i) and Rule 17d-1 became common as the BDC sector grew; section 6(c) ETF exemptive orders dominated until Rule 6c-11 (the 2019 "ETF Rule") largely obviated bespoke ETF orders; manager-of-managers, multi-class/multi-manager, and fund-of-funds relief have remained recurring categories. APP ORDR submissions on EDGAR have been PDF-native throughout, with no ASCII-text or HTML era to reconstruct. The metadata.json JSON wrapper is a normalisation layer added during ingestion; the equivalent raw EDGAR artefact is the SGML submission referenced by linkToTxt.
Three nuances matter for downstream use. First, the filer-of-record CIK in the accession number is the SEC staff sentinel 9999999997, not the applicant; applicant identity must be read from entities[0] or parsed from the PDF caption. Second, when an order names co-applicants, only the lead applicant typically appears in entities; recovering the full applicant list requires PDF text extraction. Third, conditions are not in the order — they are in the application — so any analysis of substantive regulatory terms must follow the 812-NNNNN docket back to the 40-APP/40-APP/A filings outside this dataset. The description and items fields can carry multiple YYYYMMDD tokens; the latest typically corresponds to the order's posting milestone, while earlier tokens reference the notice release or original application item dates.
Form APP ORDR is unusual on EDGAR: the filer of record is the Securities and Exchange Commission itself, not an outside registrant. The orders are entered by the Division of Investment Management — typically under delegated authority through the Chief Counsel's Office or the Office of Investment Company Regulation — and submitted to EDGAR under a Commission staff sentinel CIK in the 9999999997... range. That CIK pattern is reserved for Commission-issued and administrative documents and is not associated with any operating registrant. The applicants — the parties whose conduct the order actually governs — are named in the caption and body of the order but are never the EDGAR filer.
The trigger originates with the applicant, who initiates the process by submitting Form 40-APP (with any 40-APP/A amendments) requesting exemptive relief. The applicant population includes:
Relief is sought primarily under the Investment Company Act of 1940. The provisions most commonly invoked are Section 6(c) (general exemptive authority), Section 17(b) (affiliated transactions), Section 17(d) and Rule 17d-1 (joint transactions and co-investment), Section 57(i) (BDC affiliated transactions), Section 15(a) (advisory contracts and manager-of-managers structures), Section 12(d)(1) (fund-of-funds), and Section 22(d) (sales-load and pricing uniformity). Companion relief is occasionally granted under Section 206A of the Investment Advisers Act of 1940 and, where applicable, Section 36 of the Securities Exchange Act of 1934.
After the 40-APP is filed and any staff deficiencies are resolved, the Commission publishes a notice of application in the Federal Register and as an Investment Company Act release in the IC-3xxxx series. A 25-day notice period then runs during which any interested person may request a hearing. If no hearing is requested, the order issues automatically as a matter of course — that signed order is the document captured in this dataset.
The cadence is event-driven, not periodic. Volume tracks application inflow, staff workload, and rule changes. Adoption of Rule 6c-11 in 2019 sharply reduced bespoke ETF exemptive orders by allowing most plain-vanilla ETFs to operate without individual relief; historical concentrations otherwise cluster around BDC co-investment frameworks, manager-of-managers arrangements, and multi-class structures.
The applicant's 40-APP submission and the Commission's APP ORDR response are separate EDGAR records under different filer CIKs. Routine no-action letters, interpretive releases, and rulemaking orders do not appear under this form type and are mapped against APP ORDR more fully in the next section.
APP ORDR is the Commission's dispositive order granting or conditionally granting exemptive relief, almost exclusively under the 1940 Act. Several EDGAR form codes track the same matter at different stages, and several SEC.gov publication vehicles carry the same text under different identifiers. The map below distinguishes them by practical EDGAR signal.
40-APP / 40-APP/A — the underlying application (and amendments). The substantive request the order adjudicates. Filed by the applicant (fund complex, ETF sponsor, BDC, affiliated transaction party), it sets out the factual record, the statutory sections at issue (typically §§ 6(c), 17(b), 17(d), 12(d)(1), 22(d), 23(c)), prior precedent, and the conditions offered. APP ORDR incorporates rather than restates these facts; full research requires reading both. EDGAR signal: form code 40-APP or 40-APP/A, filer CIK is the applicant (not the SEC), header captioned "Application for an Order."
APP NTC — notice of application. Issued by the Commission before the order to solicit § 40 hearing requests. Same caption and applicants, earlier in the lifecycle. EDGAR signal: form code APP NTC, filer CIK is the SEC's, header "Notice of Application," typically a 25-day comment window stated in the body.
APP WD / APP WDR — withdrawn applications. Application pulled by the applicant; no APP ORDR will follow. Useful as a negative signal of abandoned relief theories. EDGAR signal: form codes APP WD or APP WDR, filer CIK is the applicant.
40-OIP / 40-OIP/A — orders instituting administrative proceedings. Despite the "40-" prefix and the word "order," these are adjudicatory/enforcement orders (e.g., § 9(b) ineligibility waivers, settled proceedings), not exemptive grants. EDGAR signal: form code 40-OIP, header beginning "Order Instituting Administrative Proceedings"; body cites adjudicatory provisions and Rules of Practice rather than § 6(c) exemption analysis.
§ 12(h) and other Exchange Act registrant exemption orders. Reporting-relief requests by ordinary operating issuers run on a separate administrative track and do not use APP ORDR. They typically surface as correspondence or issuer-specific filings under the relevant operating-company CIK; the order body cites Exchange Act sections, not 1940 Act sections.
Section 206A Advisers Act relief. Pure Advisers Act exemptive relief is uncommon and not consistently coded as APP ORDR. When relief spans both Acts it may ride on the APP/APP ORDR machinery; disambiguate by statutory citations in the order body (Advisers Act §§ 202, 203, 206 vs. 1940 Act §§ 6, 17).
Investment Company Act releases (IC-XXXXX). The Commission's editorial release series. The notice and order are published as numbered IC releases on SEC.gov and Federal Register; the same documents are archived on EDGAR as APP NTC and APP ORDR. EDGAR signal: the IC release number is printed in the order header — cross-reference by IC number, applicant name, and date.
No-action letters. Issued by Division staff (Investment Management, Corp Fin, Trading and Markets), not the Commission. Not on EDGAR, no precedential weight, binds only staff enforcement posture. APP ORDR, by contrast, is a Commission-level order with precedential effect for similarly situated applicants.
Rule-change and interpretive releases (33-, 34-, IC-, IA- series). General policy instruments, not adjudication of a named applicant. Published as Federal Register releases; not filed as APP ORDR.
APP ORDR is uniquely the Commission's adjudicated, applicant-specific exemptive order under the 1940 Act, archived on EDGAR with the SEC as filer. It is neither the request (40-APP), the pre-decision notice (APP NTC), an enforcement order (40-OIP), a staff position (no-action letter), nor a rule release. Pair it with 40-APP for the full record; use APP NTC and APP WD for lifecycle and negative-signal context; treat 40-OIP and § 12(h) orders as separate regimes that merely share naming or numbering conventions.
Form APP ORDR orders are operative legal instruments that let funds, advisers, BDCs, and ETF sponsors operate outside default rules of the Investment Company Act of 1940. The audience is narrow and highly specialized: the people who draft, rely on, monitor, or study that exemptive machinery.
In-house fund counsel and outside 1940 Act partners use prior orders as the primary precedent base when drafting new applications: manager-of-managers, BDC co-investment, fund-of-funds, multi-class, and bespoke ETF relief. They filter by statutory hook (Sections 6(c), 17(b), 17(d)/57(i), 12(d)(1)(A)–(G), 15(a)) and by entities to surface comparable applicants, then mine each PDF for the recitals (fact-pattern match), the citation framework, and the enumerated conditions following IT IS ORDERED, which they often lift verbatim. The filedAt field flags which orders are recent enough to reflect current Division of Investment Management staff positions.
CCOs at advisers, registered fund complexes, and BDCs use the dataset to pin down the precise scope of every order their firm relies on and to operationalize ongoing conditions. The conditions section defines the compliance program: independent-trustee approvals, quarterly board reporting, valuation procedures for co-invested positions, allocation methodologies, and recordkeeping. They monitor filedAt and entities for amendments or superseding orders and map each condition into policies, board materials, and Rule 38a-1 testing.
Independent trustees and their dedicated counsel vet specific transactions, such as proposed co-investments, affiliated joint arrangements, or follow-on allocations, against the operative order. They review the conditions language directly, not a summary, in board packets and reference it in meeting minutes when approving transactions covered by the order.
Policy staff at the Commission and at industry trade groups representing fund complexes, advisers, BDCs, and independent directors aggregate orders to track shifts in relief categories, condition templates, and staff positions. They join filedAt, entities, and statutory citations inside the PDFs to chart how condition language has evolved, for example tightening of BDC co-investment terms or convergence of ETF conditions in the run-up to Rule 6c-11.
Scholars in financial regulation, administrative law, and corporate law use the corpus for empirical work on administrative discretion, the pace of exemptive policy, and fund-product innovation. Complete coverage from 2009 forward, paired with structured metadata, supports longitudinal datasets linking applicant identity, statutory section, condition wording, and order outcome.
Reporters covering fund launches, novel BDC strategies, ETF approvals, and interval-fund structures use individual orders as primary-source confirmation of what a sponsor is actually permitted to do. They pull entities and linkToFilingDetails for citation and quote the recitals or conditions when explaining the mechanics of a new product.
Strategy and research teams at asset managers and BDC sponsors track competitor orders to map the frontier: who has secured co-investment relief, which fund-of-funds and multi-manager structures have been approved, and what exotic ETF mechanics have cleared. They watch entities and filedAt for new grants, then read the conditions to gauge the operational cost and feasibility of replicating the structure.
Teams building legal-research copilots, citation tools, and condition-extraction agents ingest the PDFs into retrieval pipelines. accessionNo, entities, and filedAt anchor metadata filters; the PDF text (recitals, statutory citations, and the IT IS ORDERED clauses with their enumerated conditions) supplies the corpus for fine-tuning and retrieval-augmented generation focused on 1940 Act exemptive practice, condition drafting, and precedent surfacing.
Every user reads the same PDFs but anchors on different parts: metadata for filtering and identification, recitals for fact-pattern matching, statutory citations for relief mapping, and the ordered conditions for the operative obligations that govern fund operations after the order issues.
A 1940 Act partner drafting a new 40-APP filters the corpus on statutory hook (e.g., Sections 17(d)/57(i) plus Rule 17d-1 for BDC co-investment, or Section 6(c) plus Section 15(a) for manager-of-managers) by grepping the action-title line and recital paragraphs of each PDF, then narrows by applicant type via entities[0].companyName and by recency via filedAt. The output is a precedent table of accession numbers, IC release numbers parsed from the order header, and 812-NNNNN dockets that supports a citation appendix and supplies condition language to lift into the new application.
A BDC or fund-complex CCO maintains a register of every APP ORDR the firm relies on. For each order they pull the PDF via linkToFilingDetails, walk the 812-NNNNN docket back to the underlying 40-APP/40-APP/A (where the numbered conditions actually live, since the order only incorporates them by reference), and map each condition — independent-director approvals, quarterly board reporting, allocation methodology, valuation procedures, recordkeeping — to a control in the Rule 38a-1 program. filedAt and description/items tokens are monitored to detect superseding orders or amendments that change the operative conditions.
Policy staff and competitive-intelligence teams build a longitudinal panel by parsing the all-caps action title and statutory citations in every PDF, joining on entities, fileNo (the 812-NNNNN docket), and filedAt. The resulting dataset charts, year by year, which sponsors obtained Section 17(d)/57(i) co-investment relief, which complexes secured Section 15(a) manager-of-managers orders, and how condition templates (board composition, allocation pro-rata mechanics, follow-on rules) tightened or loosened. Outputs include market-share charts of relief-by-sponsor and diff reports of condition wording across cohorts.
Researchers studying administrative discretion and ETF product innovation isolate Section 6(c) ETF exemptive orders issued before the 2019 ETF Rule by filtering action titles for ETF relief language and filedAt < 2019-09-25. Pairing each order with its 40-APP application yields a clean corpus for empirical work on processing time (notice-to-order intervals computed from Item YYYYMMDD tokens and IC release numbers), condition convergence, and the substitution effect of Rule 6c-11. The dataset's complete 2009-forward coverage supports survival analysis and event studies tied to specific Division of Investment Management policy shifts.
A legal-tech team ingests every accession folder into a retrieval-augmented generation stack: metadata.json populates structured filters (accessionNo, entities, fileNo, filedAt, statutory act code), and OCR/text extraction over filename1.pdf chunks the recitals, findings, and IT IS ORDERED clauses for embedding. Co-applicants missing from entities are recovered by parsing the PDF caption block. The pipeline answers questions like "find recent BDC co-investment orders with non-traded feeder structures" or "draft a conditions section modelled on the last five multi-class orders," with citations resolving back to linkToFilingDetails and the upstream 812-NNNNN docket.
Cross-referencing APP ORDR accessions against APP NTC notices and APP WD/APP WDR withdrawals on the same 812-NNNNN docket lets compliance and strategy teams build a lifecycle dashboard: applications noticed but not yet ordered, applications withdrawn (a negative signal of abandoned relief theories), and orders issued without prior amendment. The IC release number printed in each PDF header is the join key back to the corresponding APP NTC and to the Federal Register publication, closing the loop between EDGAR filings and the editorial release series.
The Form APP ORDR Files Dataset is distributed as monthly ZIP containers organized by year and month. Three access paths are available: the dataset index JSON for programmatic discovery, the full dataset archive for one-shot downloads, and per-month container ZIPs for incremental ingestion.
Dataset Index JSON API: https://api.sec-api.io/datasets/form-app-ordr-files.json
This endpoint returns dataset-level metadata (name, description, updatedAt, earliestSampleDate, totalRecords, totalSize, form types, container format, and file types) along with the full list of container files. Each container entry includes its key, size, record count, last-updated timestamp, and a direct download URL. Polling this endpoint is the recommended way to detect which monthly containers were refreshed in the latest run and to drive day-by-day incremental syncs. No API key is required to read the index.
1
{
2
"datasetId": "1f13365b-9ae0-6992-b16e-cce087ab1757",
3
"datasetDownloadUrl": "https://api.sec-api.io/datasets/form-app-ordr-files.zip",
4
"name": "Form APP ORDR Files Dataset",
5
"updatedAt": "2026-04-29T03:02:04.939Z",
6
"earliestSampleDate": "2009-01-01",
7
"totalRecords": 1230,
8
"totalSize": 60867728,
9
"formTypes": ["APP ORDR"],
10
"containerFormat": "ZIP",
11
"fileTypes": ["PDF", "JSON"],
12
"containers": [
13
{
14
"downloadUrl": "https://api.sec-api.io/datasets/form-app-ordr-files/2026/2026-04.zip",
15
"key": "2026/2026-04.zip",
16
"size": 412318,
17
"records": 9,
18
"updatedAt": "2026-04-29T03:02:04.939Z"
19
}
20
]
21
}
Download Entire Dataset: https://api.sec-api.io/datasets/form-app-ordr-files.zip?token=YOUR_API_KEY
Fetches a single archive containing every monthly container from January 2009 to the latest refresh. Suitable for initial bulk loads. This endpoint requires an API key.
Download Single Container: https://api.sec-api.io/datasets/form-app-ordr-files/2026/2026-04.zip?token=YOUR_API_KEY
Downloads one monthly container, useful for daily or monthly incremental updates. This endpoint requires an API key.
Example using curl:
curl -o 2026-04.zip "https://api.sec-api.io/datasets/form-app-ordr-files/2026/2026-04.zip?token=YOUR_API_KEY"
After decompression, each accession-number folder contains a metadata.json describing the filing plus the Commission's order and any exhibits as PDF documents.
Form APP ORDR is a Commission-issued order that disposes of an application for exemptive relief, almost exclusively under the Investment Company Act of 1940. The order grants or conditionally grants the relief requested in an underlying 40-APP application, citing the statutory sections invoked (commonly §§ 6(c), 17(b), 17(d)/57(i), 15(a), 12(d)(1), 22(d)) and incorporating the conditions set out in the application by reference.
The Securities and Exchange Commission itself is the EDGAR filer of record, posting orders through the Division of Investment Management under delegated authority. The submission goes in under a Commission staff sentinel CIK in the 9999999997... range, not under the applicant's CIK; the applicant's identity appears in entities[0] of metadata.json and in the PDF caption.
The trigger originates with an applicant — a registered investment company, ETF sponsor, BDC, investment adviser, or affiliated person — filing a 40-APP application requesting exemptive relief. After staff review, the Commission publishes a notice of application (APP NTC and a numbered IC release) and runs a 25-day hearing-request window. If no hearing is requested, the order issues automatically and is captured as the APP ORDR record.
40-APP is the applicant's request for relief, filed by the fund complex, ETF sponsor, BDC, or affiliated transaction party under their own CIK. APP ORDR is the Commission's dispositive ruling on that request, filed by the SEC under the staff sentinel CIK. The conditions that govern post-order conduct live in the 40-APP, while the order itself contains the recitals, findings, and IT IS ORDERED clause that grant the relief subject to those conditions. Full research therefore requires both records on the same 812-NNNNN docket.
metadata.json file?metadata.json is a normalized JSON summary of each submission carrying formType (always "APP ORDR"), accessionNo, filedAt, linkToFilingDetails (the order PDF URL), linkToHtml, linkToTxt, description and items arrays with Item YYYYMMDD tokens, a documentFormatFiles array, and an entities array with companyName, cik, fileNo (the 812-NNNNN docket), irsNo, and act (always "98" for the 1940 Act). Fields like seriesAndClassesContractsInformation, dataFiles, and linkToXbrl are present but empty for APP ORDR records.
No — coverage in this dataset begins on 2009-01-01. Earlier Commission orders on applications for exemptive relief exist in Commission release archives and the Federal Register but are not part of the APP ORDR EDGAR collection captured here.
Each order can be cited by its IC release number, printed on the statute-and-release line of the PDF (currently in the IC-35xxx range), together with the application docket 812-NNNNN from the caption box and the release date. The EDGAR accession number from the folder name and metadata.json, plus linkToFilingDetails, provide a stable archival pointer back to the PDF.
The dataset is published as monthly ZIP containers keyed form-app-ordr-files/<YYYY>/<YYYY>-MM.zip, with the dataset index JSON exposing per-container updatedAt timestamps. Polling the index endpoint at https://api.sec-api.io/datasets/form-app-ordr-files.json is the recommended way to detect refreshed monthly containers and drive incremental syncs.