The Form CERT Files Dataset is a normalized, per-accession collection of every Form CERT submission filed on EDGAR since the SEC mandated electronic filing of exchange certifications on August 1, 2013. Form CERT is the certification a national securities exchange — NYSE, NYSE American, NYSE Arca, Nasdaq, Cboe BZX, Cboe EDGX, IEX, and other registered exchanges — files with the U.S. Securities and Exchange Commission to confirm that a specified class of securities has been approved for listing and registration under Section 12(d) of the Securities Exchange Act of 1934. Each record represents a single certification event for one issuer's security (or a small group of related securities, such as the components of a SPAC unit or multiple share classes of an ETF) and is delivered as a structured metadata.json paired with the certification PDF as filed. The dataset is the dedicated, exchange-side timestamp for the Section 12(d) listing approval that pairs with the issuer's Form 8-A on entry and Form 25 on exit, and it is distributed in monthly ZIP containers refreshed daily.
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 contains every Form CERT accession accepted by EDGAR from August 1, 2013 forward, filtered to form type CERT, deduplicated, normalized into a per-accession folder, and pre-filtered to drop image attachments. Form CERT is filed by a national securities exchange in its capacity as a self-regulatory organization registered under Section 6 of the Exchange Act, certifying to the Commission that the exchange has approved a specified security for listing under Section 12(d). The certification is the formal mechanism by which an exchange notifies the SEC that an issuer's Form 8-A (or, for debt or other instruments, the relevant registration application) has been received, processed, and approved on the exchange's side, allowing registration of the security under Section 12 to become effective.
Each record materializes as a per-accession folder named after the EDGAR accession number with all dashes removed (for example, accession 0001354457-25-000755 becomes the folder 000135445725000755). Inside that folder are exactly two artifacts: a metadata.json describing the submission, and the certification document supplied by the filing exchange — a PDF in essentially every record. There are no nested subfolders, no multi-document bundles, and no XBRL or XML data files. A Form CERT submission is a flat, two-file unit, and the dataset preserves that one-to-one shape.
Until 2013, these certifications were submitted only on paper. The Commission's amendment to Rule 101(a) of Regulation S-T mandated electronic filing of Form CERT through EDGAR, and the dataset begins on August 1, 2013, when that mandate took effect. Pre-2013 paper certifications are out of scope. The dataset is distributed as monthly ZIP containers; the file types found inside any container are exactly PDF (the certification document) and JSON (the metadata).
A record has two complementary layers:
The original EDGAR .txt SGML wrapper is not redelivered as a separate file inside the folder, but its URL is recorded in the metadata's linkToTxt field and an entry for it appears in documentFormatFiles.
metadata.json is a single JSON object with a fixed top-level shape. Its fields fall into four groups.
Filing identity and timestamps. formType is always the literal string "CERT". accessionNo is the dashed EDGAR accession number (e.g., "0001354457-25-000755"). filedAt is the ISO-8601 timestamp of the EDGAR submission with timezone offset; effectivenessDate is the ISO date on which the certification took effect, which for Form CERT is normally the same calendar day as filedAt. description is the human-readable form description (e.g., "Form CERT - Certification by an exchange approving securities for listing"). id is a 32-character hexadecimal internal identifier.
Links back to EDGAR. linkToFilingDetails is the direct URL to the primary CERT PDF on sec.gov. linkToTxt points to the complete EDGAR .txt submission wrapper. linkToHtml points to the EDGAR filing-index HTML page for the accession. linkToXbrl is empty for Form CERT.
Document inventory. documentFormatFiles is an array of objects describing each document attached to the original EDGAR submission. Each item carries a sequence index, a byte size, a documentUrl on sec.gov, an EDGAR document type (typically "CERT" for the certification itself), and an optional description string. The description is where the exchange origin frequently surfaces — values such as "NYSE CERTIFICATION", "NYSE ARCA CERTIFICATION", or "CBOE BZX CERTIFICATION" are common, and a synthetic "Complete submission text file" entry represents the SGML wrapper. dataFiles is the parallel array for structured data attachments and is empty for Form CERT.
Filer/entity block. entities is an array of one or more entity objects. For a typical Form CERT, there is a single entity whose companyName carries a parenthesized role suffix — "(Filer)". Each entity object carries the registrant's CIK, irsNo (IRS employer identification number), fileNo (the SEC file number, frequently of the form 001-XXXXX for Section 12(b) listings), filmNo (EDGAR's internal film number for the submission), act (the act under which the filing is made — "34" for the Exchange Act), type (the EDGAR submission type, "CERT"), stateOfIncorporation (a two-letter code such as DE for Delaware or an EDGAR-style code such as E9 for the Cayman Islands), and fiscalYearEnd in MMDD form. An optional sic industry code with label (e.g., "6770 [Blank Checks](https://www.law.cornell.edu/cfr/text/17/230.419)") appears when EDGAR has classified the registrant. When ticker information is available for the security being listed, a tickers array enumerates the symbols associated with the listing, which is particularly useful for issuers registering multiple classes simultaneously (for example, common stock, units, and warrants of a SPAC, or three share classes of an ETF). seriesAndClassesContractsInformation is reserved for fund-style series/class metadata and is generally empty for Form CERT.
The single non-metadata file in each accession folder is a binary PDF (%PDF-1.7 header) representing the certification document. The filename is filer-supplied and varies widely — examples include 8A_Cert_HCMA.pdf, FDXNotes073125.pdf, EVMO073125.pdf, and 8A_Cert_PCI_PCL_PCS.pdf — so the filename should not be relied on for parsing. The document role is fixed by the folder structure and confirmed by the matching documentFormatFiles entry whose type is "CERT".
The body is typically a single page, on the order of tens to a few hundred kilobytes. Although wording differs by exchange, the structural content is uniform and consists of the following elements, generally in this order:
A single Form CERT may certify several related securities in one document — for example, all three share classes of an ETF, multiple note tranches of a single issuer, or the three components of a SPAC unit (common stock, units, warrants). In that case the security-title section of the PDF lists each item explicitly, and the tickers array in the metadata, when populated, typically parallels this multiplicity.
Each record includes the structured metadata.json and the certification PDF as filed on EDGAR. The metadata captures the identifiers needed to locate, cross-reference, and audit the filing on sec.gov, plus the document inventory and registrant information drawn from the EDGAR submission header. The PDF preserves the operative legal text, the exchange's signature, and any visible letterhead or formatting from the certifying exchange.
Image files attached to the original EDGAR submission are excluded by design; in practice this is rarely material because Form CERT submissions consist almost exclusively of a single PDF. The complete EDGAR submission text wrapper (.txt) is not redelivered as a separate file inside the folder, but its URL is recorded in linkToTxt and as an entry in documentFormatFiles. Related filings that surround a listing event — the issuer's Form 8-A, the related registration statement, the Form 25 if the listing is later removed, or any 8-K announcements — are separate EDGAR submissions with their own accession numbers and are not part of this dataset.
The substantive content of Form CERT has been remarkably stable: the certification remains a short exchange-authored letter under Section 12(d) and Rule 12d1-1, and its constituent elements (exchange identity, registrant, security title, file reference, application date, conditions, signature) have not been materially altered by Commission rulemaking during the electronic-filing era. What has changed is the population of certifying exchanges, as new venues have registered as national securities exchanges (for example, the Long-Term Stock Exchange and the Members Exchange) and as exchange branding has shifted (for example, the rebranding of BATS to Cboe BZX). These changes appear as new letterhead and signatory variations rather than as structural changes to the record.
The dominant format shift for Form CERT is the transition from paper to EDGAR. Before 2013, certifications were submitted only on paper and are not reflected in this dataset. The amendment to Rule 101(a) of Regulation S-T made electronic filing mandatory, and August 2013 marks the start of coverage. From that point onward, the standard delivery has been a PDF document submitted through EDGAR, accompanied by the standard EDGAR header metadata. The form has not migrated to HTML; the filing is a PDF in essentially every record, which is why the file types found in the dataset are exactly PDF and JSON. Within the PDF era, the only visible evolution is in incidental presentation: PDF generator versions, exchange letterhead redesigns, and small changes in signatory titles. The structural role of the document and the shape of the metadata wrapper have remained constant.
Several nuances matter for downstream use:
entities[].companyName field carries a parenthesized role suffix ("(Filer)") that must be stripped to obtain a clean issuer name.fileNo field is the SEC file number for the registrant's Section 12 record (typically 001-XXXXX for exchange-listed issuers) and is the most reliable join key to other SEC corporate filings, alongside cik.effectivenessDate and filedAt are normally the same calendar day for Form CERT but should be treated as distinct fields: filedAt is a timezone-aware timestamp, while effectivenessDate is a date-only value.tickers array to enumerate the individual instruments.documentFormatFiles[].description (e.g., "NYSE ARCA CERTIFICATION") and visible in the PDF letterhead, but downstream analysis that needs a clean exchange dimension must derive it.CERT, and the formType field always reflects the underlying EDGAR designation.Form CERT is filed by a national securities exchange, not by the issuer of the listed security. The filer is the exchange in its capacity as a self-regulatory organization (SRO) registered under Section 6 of the Securities Exchange Act of 1934. The exchange submits the certification through its own EDGAR account, under its own CIK, attesting that it has approved a specified class of securities for listing and registration.
The recurring filers in this dataset are the U.S. national securities exchanges with listing authority, including:
The issuer whose security is being listed appears inside the body of the certification (issuer name, issuer CIK, title of the security, listing application date) but is not the EDGAR submitter. Form CERT therefore appears on the exchange's EDGAR page, not on the issuer's filing history.
Form CERT is event-driven. There is no periodic schedule, no fiscal-period deadline, and no filer-status calendar. A new Form CERT is generated each time an exchange completes its internal listing approval for a particular class of securities and certifies that approval to the SEC.
The typical sequence:
The exchange typically files Form CERT on or about the day trading begins, coordinated with the issuer's Form 8-A and any related prospectus effectiveness. Triggering events include initial public listings, listing transfers between exchanges, additional series of preferred stock, depositary shares, warrants, units, or rights, and new tranches of debt, structured products, ETFs, and closed-end funds. High-volume product issuers (ETF sponsors, structured-note programs) generate many Form CERT submissions per year, often in batches.
Note: Rule 12d1-1 under the Exchange Act addresses the limited registration of additional classes when an issuer already has a class registered under Section 12(b) on the same exchange and is procedural rather than the primary substantive basis for Form CERT. The core authority for Form CERT itself is Section 12(d).
Form CERT is unusual: it is filed by a national securities exchange, not the issuer, and its only legal effect is to certify that a security has been approved for listing and registration under Section 12(d) of the Exchange Act. The most useful comparisons therefore run along three axes — issuer-side registration filings around the same listing event, the lifecycle counterpart that ends a listing, and other exchange-side filings that govern rules rather than individual securities.
Form 8-A is the closest functional sibling. It is the short-form registration statement an issuer files under Section 12(b) or 12(d) to register a class of securities for exchange listing. The two filings complete the same Section 12 registration event from opposite sides: the issuer files 8-A to register the class and incorporate prospectus disclosures by reference; the exchange then files CERT to certify that listing approval has been granted. 8-A carries issuer identity and a description of securities; CERT carries exchange name, security title, registrant CIK, application date, and any conditions. They are complements, not substitutes — a complete Section 12 record needs both.
Form 25 is the lifecycle counterpart. CERT marks admission to the list; Form 25 marks removal from listing and/or registration under Section 12(b). Both are short, event-driven procedural notices with no financial content. They differ in direction (entry vs. exit), in filer (Form 25 may be filed by either the exchange or, in voluntary delistings, the issuer), and in downstream effect on Exchange Act reporting obligations. A full listing-history record pairs CERT (entry) with Form 25 (exit).
Form S-1 (domestic), Form F-1 (foreign private issuer), and 424 prospectuses final prospectuses are Securities Act registration and offering documents filed by issuers. They appear in the same calendar window as CERT during an IPO but operate under a different statute and serve a different purpose: they disclose the offering — financial statements, MD&A, risk factors, use of proceeds, underwriting terms. CERT is an Exchange Act listing certification with no financial or narrative content and a fixed procedural template. An IPO typically generates S-1, 424, 8-A, and CERT in sequence; CERT is the last and the only one filed by the exchange. Use S-1/F-1/424 for offering and disclosure analysis; use CERT only for the exchange-side listing timestamp.
19b-4 is the other major class of exchange-filed submission, made under Section 19(b) to propose changes to exchange rules (trading, listing standards, fees, market structure). On the "exchange-as-filer" axis it is CERT's natural neighbor, but the subject is different: 19b-4 governs the rulebook; CERT governs the application of those rules to a single security. 19b-4 filings are typically long, run through public comment, and require SEC approval or disapproval; CERT filings are routine, security-by-security, and not subject to comment. Researchers studying exchange policy use 19b-4; researchers tracking which securities became listed use CERT.
Form 1-A is an issuer-filed Securities Act offering statement for exempt Reg A offerings, qualified by SEC staff. It is included here mainly to dispel confusion: Regulation A is an alternate, smaller-scale route to public capital that does not by itself trigger a CERT. A CERT only appears if a Reg A issuer separately pursues a national exchange listing. The populations are almost non-overlapping and the research questions unrelated.
A generic EDGAR corpus contains every accepted submission, including Form CERT. The CERT dataset is a strict subset, filtered to form type CERT, deduplicated, normalized into per-accession metadata plus document files, and pre-filtered to drop image attachments. Use the full EDGAR mirror when CERT is one of many form types under study; use the dedicated CERT dataset when listing-certification events are the primary object — it removes the indexing, parsing, and filtering work for the CERT accessions filed since mandatory electronic filing in August 2013.
Form CERT is distinct on four axes at once:
CERT is not a substitute for 8-A, S-1, F-1, or 424 when the question concerns disclosure, finances, or offering terms, and it is not a substitute for 19b-4 when the question concerns exchange policy. It is the authoritative source for the exchange-side timestamp on a security's Section 12(d) listing approval, and it pairs naturally with 8-A on entry and Form 25 on exit to construct a full listing lifecycle.
The Form CERT record exposes a small but authoritative set of fields — exchange name, registrant CIK, security title, file number, application date, and certification date, plus any conditional language. Different professional functions draw on different fields of the same record.
ECM analysts use Form CERT to mark the exact moment a security becomes listable. They reconcile S-1 or S-3 effectiveness against the exchange-side approval using CIK, security title, exchange, and certification date, then time first-trade windows and feed clean listing events into pricing books, allocation models, and aftermarket performance dashboards.
Listing counsel and disclosure attorneys verify that the Section 12(d) step was completed and inspect any conditions imposed by the exchange. They rely on the application-filing date, certification date, exchange, security title, and conditional language to support post-closing checklists, perfection of registration before further corporate actions, and precedent research on conditional listings.
Quant researchers studying venue competition and listing migration build exchange-level time series from the exchange field and certification date at scale, joining CERT records with 8-A, Form 25, and 25-NSE filings to construct full venue-of-listing histories per CIK. Outputs include market-share studies and event designs that need an exchange-confirmed listing timestamp rather than the issuer-side registration date.
Product teams covering ETFs, ETNs, and closed-end funds filter on registrant CIK, security title, and exchange to track sponsor activity and new-series launches within master trusts. The certification date drives launch calendars, cohort survival studies, and competitive analysis of listing pace across venues.
Blank-check analysts use CERT to fix the exchange-approved listing date for units, common shares, and warrants, then again for the surviving entity post-combination. The security-title field is central, since it distinguishes units from common from warrants. Records feed SPAC trackers and event studies covering separation, redemption, and warrant economics.
Researchers measuring underpricing and aftermarket returns use the certification date as the cleanest exchange-confirmed reference event, more authoritative than press releases or vendor listing trackers. CIK, security title, exchange, and certification date align return series, bound first-day windows, and build matched control samples.
Data engineers building security masters and corporate-action feeds parse the JSON metadata for exchange, file number, security title, and CIK, then link to ticker-mapping tables to populate listing-status flags. CERT serves as a primary source for listing-event audit trails and quality-control checks against vendor-supplied listing dates.
Compliance officers at broker-dealers, market makers, and clearing firms confirm Section 12 registration and any tied conditions before extending market-making, margin, or clearing services. They key on CIK, exchange, security title, certification date, and conditional language for onboarding controls, eligibility checks, and post-trade reconciliations.
Empirical researchers studying listing-venue choice, exchange competition, and post-listing outcomes use the historical CERT corpus as a structured event database, joining certification date, exchange, security title, and CIK with return data and other EDGAR forms.
Teams building filings-search assistants ground retrieval on the JSON metadata — CIK, exchange, security title, file number, certification date — and use the source PDFs for document-level question answering. The dataset powers listing-status lookups and corporate-action timelines in financial copilots.
Form CERT records pin down the exchange-side timestamp and security title for every Section 12(d) listing approval since August 2013. The use cases below show how teams operationalize that fact.
Reference-data engineers join entities[].cik and effectivenessDate across the full CERT corpus, then merge with Form 8-A (entry) and Form 25 (exit) accessions to construct a complete venue-of-listing history per registrant. The certifying exchange is derived from documentFormatFiles[].description (for example, "NYSE ARCA CERTIFICATION"). Output: a per-CIK listing ledger with venue, security title, entry date, and exit date used to audit security-master listing flags against vendor feeds.
IPO and underpricing researchers use effectivenessDate together with entities[].cik and the security titles parsed from the PDF body as the t=0 anchor for first-day, first-week, and first-month return windows. CERT supplies an exchange-confirmed timestamp that is cleaner than press releases or vendor "list date" fields and aligns naturally with S-1/424 effectiveness pulled from the same registrant.
De-SPAC and blank-check analysts filter records where the PDF security-title section enumerates "Units," "Class A Common Stock," and "Redeemable Warrants" for one issuer, frequently confirmed by a multi-symbol tickers array. The certification event marks the listable date for each component; analysts feed these into separation-window monitors and warrant-economics studies, then re-pull CERT records for the post-combination successor.
ETF product researchers filter CERTs whose documentFormatFiles[].description indicates NYSE Arca, Nasdaq, or Cboe BZX, link entities[].cik to known issuer trusts, and treat each accession as a series-launch signal. Outputs include weekly launch counts by sponsor, exchange-share trends in new product listings, and cohort tables for survivorship analysis.
Listing counsel run text extraction (with OCR fallback for scanned PDFs) on the certification document to find conditional or qualified approval language, then store hits keyed by exchange, fileNo, and effectivenessDate. The resulting precedent set supports negotiation of conditions on future listings and post-closing checklists that must verify perfection of Section 12 registration before subsequent corporate actions.
LLM and RAG developers index metadata.json for filtering (CIK, file number, exchange description, effectiveness date) and the certification PDF for passage-level question answering. Typical queries served: "When was security X approved for listing on exchange Y?", "What conditions did the exchange impose?", and "Which CERTs were filed by Cboe BZX in 2024 Q4?"
Market-structure quants aggregate CERT counts by certifying exchange (derived from documentFormatFiles[].description) and by month from effectivenessDate to produce exchange-level new-listing time series. These series feed venue-competition models, listing-migration analyses (paired with Form 25), and event designs that require an exchange-confirmed listing date rather than an issuer-reported one.
Dataset Index JSON API: https://api.sec-api.io/datasets/form-cert-files.json
This endpoint returns dataset-level metadata along with the list of all available container files. The metadata covers the dataset name, description, last update timestamp, earliest sample date, total record count, total size, form types covered (CERT), container format (ZIP), and file types contained in each container (PDF, JSON). The containers array lists every monthly archive with its size, record count, last updated timestamp, relative key, and direct download URL. This makes it straightforward to monitor daily refresh runs and decide which containers to re-download as new filings are added or existing ones are updated. This endpoint does not require an API key.
Example response:
1
{
2
"datasetId": "1f13365b-9ae0-6931-b39a-169bac65f553",
3
"datasetDownloadUrl": "https://api.sec-api.io/datasets/form-cert-files.zip",
4
"name": "Form CERT Files Dataset",
5
"updatedAt": "2026-04-25T03:02:06.311Z",
6
"earliestSampleDate": "2013-08-01",
7
"totalRecords": 10384,
8
"totalSize": 1900939666,
9
"formTypes": ["CERT"],
10
"containerFormat": "ZIP",
11
"fileTypes": ["PDF", "JSON"],
12
"containers": [
13
{
14
"downloadUrl": "https://api.sec-api.io/datasets/form-cert-files/2026/2026-04.zip",
15
"key": "2026/2026-04.zip",
16
"size": 18472913,
17
"records": 92,
18
"updatedAt": "2026-04-25T03:02:06.311Z"
19
}
20
]
21
}
Each container ZIP unpacks into one folder per accession number. Every folder contains a metadata.json file describing the filing along with the original EDGAR submission documents as PDFs (image files excluded).
Download Entire Dataset: https://api.sec-api.io/datasets/form-cert-files.zip?token=YOUR_API_KEY
Downloads the complete Form CERT Files dataset as a single ZIP archive covering all filings from August 2013 to the latest refresh. This endpoint requires an API key.
Download Single Container: https://api.sec-api.io/datasets/form-cert-files/2026/2026-04.zip?token=YOUR_API_KEY
Downloads one monthly container instead of the full archive. Replace the key segment (for example 2026/2026-04.zip) with any container key returned by the dataset index JSON API. This endpoint requires an API key.
The dataset covers SEC Form CERT — the certification a national securities exchange files with the Commission to confirm that a specified class of securities has been approved for listing and registration under Section 12(d) of the Securities Exchange Act of 1934. The formType field in every record's metadata is the literal string "CERT".
Each record corresponds to one Form CERT filing on EDGAR, identified by a single SEC accession number. The record materializes as a per-accession folder containing exactly two artifacts: a metadata.json describing the submission and the certification PDF supplied by the filing exchange.
Form CERT is filed by a U.S. national securities exchange — NYSE, NYSE American, NYSE Arca, Nasdaq (Global Select, Global, and Capital Market tiers), Cboe BZX and other Cboe-affiliated listing venues, IEX, and other registered listing exchanges — acting in its capacity as a self-regulatory organization. The issuer of the listed security appears inside the body of the certification but is not the EDGAR submitter.
Form CERT is event-driven, not periodic. A new certification is generated each time an exchange completes its internal listing approval for a specific class of securities, typically on or about the day trading begins, and coordinated with the issuer's Form 8-A and any related prospectus effectiveness.
The dataset begins on August 1, 2013, when the SEC's amendment to Rule 101(a) of Regulation S-T made electronic filing of Form CERT mandatory through EDGAR. Pre-2013 paper certifications exist in SEC paper records but are out of scope.
The dataset is distributed as monthly ZIP containers. Each container unpacks into one folder per accession number, and each folder contains a metadata.json and the certification PDF as filed on EDGAR. The only file types present in any container are PDF and JSON.
Form 8-A is the issuer-side short-form registration statement under Section 12(b) or 12(d); Form CERT is the exchange-side certification that listing approval has been granted. The two filings complete the same Section 12 registration event from opposite sides — 8-A registers the class, CERT certifies that the exchange has approved it — and a complete Section 12 record needs both.