The Form POS462B Files Dataset is a collection of every EDGAR submission filed under form type POS462B — post-effective amendments to registration statements made pursuant to Rule 462(b) of the Securities Act of 1933. Each record is one complete EDGAR accession packaged as a subfolder inside a monthly ZIP container, containing a parsed metadata.json header alongside the original SGML-wrapped HTML submission documents and, where present, the EDGAR complete-submission text file. The form is filed by operating-company issuers — domestic registrants on Forms S-1, S-3, or S-11, foreign private issuers on F-1 or F-3 — to register additional securities of the same class as those covered by an earlier effective registration statement, subject to a 20 percent cap on the original maximum aggregate offering price. The dataset covers all POS462B accessions filed on EDGAR from July 1995 (the inception of mandatory EDGAR filing) through the present.
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 packages every POS462B submission made to EDGAR since July 1995. A single record is one accession — not a filing-index page and not an individual exhibit — and carries every document the registrant submitted under that accession number (other than image binaries), together with a parsed metadata header.
Physically, records are organized into monthly ZIP containers named YYYY-MM.zip. The internal path layout is YYYY-MM/<accession-no-dashes>/, where the folder name is the 18-digit, dash-stripped EDGAR accession number (for example, accession 0001104659-20-043986 becomes 000110465920043986/). The accession folder is flat — there are no nested subfolders. Inside sit a metadata.json describing the EDGAR submission header and the original submission documents as separate files. The container format is ZIP, and the file types found in the dataset are JSON (the metadata header), HTML (the SGML-wrapped .htm/.html documents the registrant filed), and TXT (the EDGAR complete-submission concatenated text file, when materialized). Image attachments (.jpg, .gif) are deliberately excluded; metadata.json is always present.
Form POS462B is itself a narrow administrative vehicle. Rule 462(b) lets a registrant register additional securities of the same class as those covered by an already-effective registration statement, provided the aggregate offering price of the additional securities does not exceed 20 percent of the maximum aggregate offering price set forth in the original "Calculation of Registration Fee" table. A 462(b) filing is immediately effective upon filing — no Staff review, no acceleration request — and is keyed to the original registration's file number rather than receiving a new one. In practice the POS462B form-type code is used for two structurally distinct purposes, both of which appear in this dataset:
Volume is modest because Rule 462(b) is itself narrow, used only when an issuer needs to top up or terminate a prior registration during a live or closing offering.
A record has three content layers, from outermost to innermost:
metadata.json — a flat JSON object that mirrors and parses the EDGAR filing header for the accession. This is the structured-data face of the record.metadata.json and the submission documents are linked through the documentFormatFiles[] array inside the metadata, which lists one entry per filed document with its EDGAR sequence number, byte size, documentUrl on sec.gov, free-text description, and EDGAR document type. The filenames in documentFormatFiles[] correspond to the files sitting next to metadata.json on disk.
metadata.json schemametadata.json is a flat JSON object summarizing the EDGAR header. The top-level keys are:
| Key | Meaning |
|---|---|
formType | EDGAR form-type code; always "POS462B" in this dataset. |
accessionNo | Dashed accession number, e.g. "0001104659-20-043986". |
linkToFilingDetails | URL of the primary filing document on sec.gov. |
description | Static human-readable description: "Form POS462B - Post-effective amendment to registration statement [Rule 462(b)]". |
linkToTxt | URL of the EDGAR complete-submission .txt file. |
filedAt | ISO-8601 filing timestamp with timezone offset, e.g. "2020-04-07T08:49:54-04:00". |
linkToHtml | URL of the EDGAR filing-index HTML page. |
linkToXbrl | URL of XBRL data; empty string "" for POS462B filings. |
id | Internal 32-character hex content identifier, e.g. "5a0a0f86eff76f31438baa68f08a5219". |
documentFormatFiles | Array — one entry per document in the EDGAR submission. |
entities | Array of filer/registrant entities derived from the EDGAR header. |
seriesAndClassesContractsInformation | Array; empty for POS462B (used only by investment-company series/class filings). |
dataFiles | Array; empty for POS462B (used for XBRL exhibit files on form types that carry them). |
documentFormatFiles[]Each element describes one document in the EDGAR submission. Fields:
sequence — EDGAR sequence number as a string ("1", "2", …). For ancillary entries such as the complete-submission text file, this field is " " (a single space).size — byte count as a string.documentUrl — sec.gov URL of the document.description — free-text description supplied at filing time.type — EDGAR document type ("POS462B" for the primary form document, "EX-5.1", "EX-23.1", etc. for opinions and consents, and " " for the complete-submission text file).A typical primary-document entry looks like:
1
{
2
"sequence": "1",
3
"size": "29644",
4
"documentUrl": "https://www.sec.gov/Archives/edgar/data/1667633/000110465920043986/a20-14980_5pos462b.htm",
5
"description": "POS462B",
6
"type": "POS462B"
7
}
A complete-submission text entry appears with "sequence": " ", "type": " ", and description: "Complete submission text file", pointing at the <accession>.txt concatenated submission file (e.g., 0001104659-20-043986.txt).
entities[]One element per role-bearing entity in the EDGAR header. Most POS462B accessions have a single registrant and therefore a single entity element. Per-entity keys:
companyName — display name with the EDGAR role suffix in parentheses, e.g. "Forty Seven, Inc. (Filer)".cik — 10-digit zero-padded Central Index Key, e.g. "0001667633".irsNo — Employer Identification Number digits, e.g. "474065674".fileNo — SEC file number, e.g. "333-235458". For POS462B this is the registration number of the earlier effective registration being amended; a new file number is never assigned to the 462(b) itself.filmNo — EDGAR film number, e.g. "20778509".formType — "POS462B", matching the top-level value.act — Securities Act under which filed, "33" (Securities Act of 1933).fiscalYearEnd — MMDD, e.g. "1231".stateOfIncorporation — two-letter U.S. state or jurisdiction code, e.g. "DE".sic — SIC code and label, e.g. "2834 Pharmaceutical Preparations".tickers — array of ticker strings, e.g. ["FTSV"].Each submission document inside the accession folder is an EDGAR SGML-wrapped HTML file. The outer envelope is the canonical EDGAR <DOCUMENT> wrapper, holding a small typed header followed by <TEXT> containing the rendered HTML body:
1
<DOCUMENT>
2
<TYPE>POS462B
3
<SEQUENCE>1
4
<FILENAME>a20-14980_5pos462b.htm
5
<DESCRIPTION>POS462B
6
<TEXT>
7
<html>... full HTML body ...</html>
8
</TEXT>
9
</DOCUMENT>
<TYPE> carries the EDGAR document type (POS462B, EX-5.1, EX-23.1, etc.); <SEQUENCE> mirrors the documentFormatFiles[].sequence value; <FILENAME> is the on-disk filename inside the accession folder; <DESCRIPTION> is the filer-supplied free-text description.
The inner HTML body is heavily inline-styled (Times New Roman, explicit point sizes on every <p> and <font> element, Wingdings glyphs for checkbox marks) and is broken into page sections using <div style="page-break-before:always;">. HTML comments such as <!-- SEQ.=1,FOLIO='',FILE='C:\JMS\...',USER='105537',CD='Apr 6 20:13 2020' --> are Workiva, Donnelley, or Toppan filing-tool artifacts placed at page boundaries and carry no legal content.
The body of the primary POS462B document follows a stable layout. In document order:
Facing page. A boilerplate header block identifying the filing. Includes the phrase "As filed with the Securities and Exchange Commission on [date]"; the line "Registration No. 333-XXXXXX" (the file number of the original registration being amended); the headline "POST-EFFECTIVE AMENDMENT NO. [N] TO FORM [S-1/S-3/F-1] REGISTRATION STATEMENT NO. 333-XXXXXX / UNDER THE SECURITIES ACT OF 1933"; the registrant name in large caps; state of incorporation; IRS Employer Identification Number; principal-office address and telephone; the name and address of the agent for service; and a "Copies to:" block listing outside counsel. A checkbox section then walks the standard Rule 415, Rule 462(b), Rule 462(c), Rule 462(e), and General Instruction I.D. paragraphs (rendered with Wingdings o/x glyphs), and a separate checkbox table marks accelerated-filer, smaller-reporting-company, and emerging-growth-company status.
Incorporation-by-reference statement. A short paragraph stating that the contents of the earlier effective registration statement (identified by file number) are incorporated by reference into the post-effective amendment. For additive 462(b) filings this statement is the legal hinge of the form: rather than reproducing the prospectus, the filing imports it wholesale and merely registers the incremental securities on top.
Calculation of Registration Fee table. Present on additive 462(b) filings. This is the Rule 457(o) "Calculation of Registration Fee" table, with columns for title of each class of securities to be registered, amount being registered, proposed maximum offering price per unit, proposed maximum aggregate offering price, and amount of registration fee. The amounts here represent only the incremental top-up (capped at 20 percent of the original maximum aggregate offering price), not the original registration. Footnotes typically state the rule under which the fee is calculated and reference the original registration's fee.
Explanatory Note. Present on deregistration/termination amendments and on many additive filings. The subtitle indicates the purpose — e.g. "DEREGISTRATION OF SECURITIES" on a termination filing — and the body recites the prior registration (file number, total aggregate offering price, class and par value of securities), the event triggering the amendment (completed offering, merger closing, abandonment of the offering), and the action taken (termination of the offering and removal of unsold securities from registration).
Exhibits — opinions and consents. Additive 462(b) filings must carry the legal opinion of counsel as to the validity of the additional securities being registered (filed as Exhibit 5.1) and the written consent of the registrant's independent registered public accounting firm (Exhibit 23.1), plus the implicit consent of counsel embedded in Exhibit 5.1. Each exhibit is filed as a separate .htm document within the same accession folder, each with its own <DOCUMENT> wrapper and its own entry in documentFormatFiles[] carrying an EDGAR exhibit type such as EX-5.1 or EX-23.1. Filenames follow the registrant's local convention (ex5-1.htm, ex23-1.htm, etc.). Deregistration/termination filings generally omit all exhibits.
Signatures. A short-form signature block governed by Rule 478, which permits a post-effective amendment under Rule 462(b) to be signed by a more limited slate of persons than a full registration statement. The boilerplate runs "Pursuant to the requirements of the Securities Act of 1933, as amended, the Registrant certifies that it has reasonable grounds to believe that it meets all of the requirements for filing on Form [S-1/S-3/F-1] and has duly caused this post-effective amendment to be signed on its behalf by the undersigned …", followed by a two-column table of /s/ <Name> lines with Name: and Title: rows. The block closes with "No other person is required to sign this Post-Effective Amendment in reliance upon Rule 478 under the Securities Act of 1933, as amended."
When the accession contains exhibits, each exhibit sits in its own <DOCUMENT> wrapper after the primary POS462B document, in EDGAR sequence order. The complete-submission .txt file, when present, is the EDGAR concatenation of all those <DOCUMENT> blocks back-to-back.
Each record includes:
metadata.json, with the schema above.POS462B document, and where applicable any Exhibit 5 opinion of counsel, Exhibit 23 consents of auditors and counsel, and any additional narrative exhibits — each delivered as its own .htm file preserving the original EDGAR <DOCUMENT> envelope and the filer's submission filename..txt concatenation, referenced through linkToTxt and through a documentFormatFiles[] entry with type: " "..jpg and .gif graphics referenced from the HTML (corporate logos, signature scans, exhibit images) are deliberately excluded.seriesAndClassesContractsInformation array is empty for this form type; that schema slot is reserved for investment-company filings.linkToXbrl is empty and dataFiles is empty.The two stylistic flavors of POS462B produce visibly different records:
The container layout, metadata.json schema, and SGML <DOCUMENT> envelope are identical across both flavors; only the document count, the EDGAR exhibit types in documentFormatFiles[], and the presence or absence of the fee/opinion/consent sections in the body differ.
The Rule 462(b) regime has been substantively stable since adoption: a 462(b) filing has always served to register up to 20 percent additional securities of the same class as a still-effective registration, has always been immediately effective on filing, and has always relied on Rule 478 for its abbreviated signature block. The qualitative content of a POS462B body — facing page, incorporation-by-reference, fee table (when additive), and Rule 478 signatures — has therefore been largely constant across the dataset's 1995-to-present span.
Disclosures within those sections have nevertheless evolved with broader SEC rulemaking:
The dataset's records span the full EDGAR document-format era. The format trajectory relevant to POS462B is:
<DOCUMENT> SGML envelope used today, but with <TEXT> blocks holding ASCII bodies rather than HTML. Tables in the fee calculation were rendered as fixed-width text with character-cell alignment.<TYPE>POS462B-wrapped HTML bodies with inline styling. By the mid-2000s HTML had become dominant for both the primary document and the exhibits.<div>s, Wingdings checkbox glyphs, and filing-agent tool comments at page boundaries..txt. Throughout the period, EDGAR has continued to generate a concatenated complete-submission text file for every accession, referenced in the dataset through the linkToTxt URL and through the type: " " entry in documentFormatFiles[].entities[].fileNo and the cover-page "Registration No. 333-XXXXXX" both point to the underlying S-1/S-3/F-1; the POS462B does not receive its own file number. Joining a POS462B record back to the original prospectus and fee table requires looking up that file number on EDGAR.formType: "POS462B". The flavor can be inferred from the document count in documentFormatFiles[] (a single primary document with no exhibits strongly suggests a termination), the file size, and the presence or absence of a Calculation of Registration Fee table in the primary document.<DOCUMENT> envelopes, separately listed in documentFormatFiles[], and separately materialized as .htm files alongside metadata.json. They are not embedded inside the primary POS462B document.<DOCUMENT> block's <TYPE>, <SEQUENCE>, <FILENAME>, and <DESCRIPTION> mirror the corresponding documentFormatFiles[] entry. Either source can be used for document-level extraction; the JSON is canonical for parsing.<!-- SEQ.=...,FOLIO=...,FILE=...,USER=...,CD=... --> reflect the filer's preparation software (Workiva, Donnelley, Toppan, in-house tools) and should be stripped for content extraction.a20-14980_5pos462b.htm follow each registrant's filing-agent conventions and are not standardized across the dataset. The reliable handles for joining files to metadata are the EDGAR sequence number and the documentUrl, not the filename pattern.sequence values in documentFormatFiles[] order the primary and exhibit documents; the complete-submission text file entry uses sequence: " " and is not part of that ordering. Sort by numeric sequence (treating " " as last) when reconstructing document order.Each POS462B is a post-effective amendment filed by the issuer/registrant that already has an effective Securities Act registration statement on file. The filing is made by the same registrant that filed the original statement, attached to the same 333- file number, and signed by the same officers and directors (or attorney-in-fact under existing powers of attorney). The form's purpose is to register additional securities of the same class as those covered by the earlier effective registration statement so that sales of those incremental securities comply with Section 5 of the Securities Act of 1933.
The filer is the issuer, not the underwriter. The underwriter's pricing-night decision to upsize or to exercise an over-allotment is the commercial driver, but the POS462B is the registrant's filing under the registrant's CIK.
POS462B is exclusively a Securities Act device used by operating-company-style registrants. Typical filers include:
The dataset does not include investment company filings (1940 Act registrants use Rule 485 amendments such as 485APOS / 485BPOS) or BDC N-2 amendments.
The form is event-driven, not periodic. It is triggered when the registrant determines, at or immediately before pricing, that additional securities of the same class must be registered beyond the amount in the earlier effective registration statement. Common trigger patterns:
Because effectiveness is automatic, the registrant self-certifies on the facing page that the filing is made pursuant to Rule 462(b) and that the additional registered amount is within the 20 percent cap.
The cap is measured in dollars (maximum aggregate offering price), not in shares, and is measured against the earlier registration statement's registered dollar amount, not against amounts actually sold. If the incremental dollar amount would exceed 20 percent, Rule 462(b) is unavailable and the issuer must use a conventional post-effective amendment or a new registration statement, neither of which is automatically effective.
The filing is effective immediately upon EDGAR acceptance. Rule 462(b) requires transmission to EDGAR no later than the date of first sale of the additional securities. In practice:
The functional deadline is the moment of first sale of the additional securities; the practical window is the few hours between pricing and settlement.
Form POS462B occupies a narrow corner of the Securities Act registration framework defined by five properties at once: a post-effective amendment, filed by an operating-company issuer, that adds new securities of the same class as an earlier effective registration, capped at 20 percent of the original maximum aggregate offering price, and immediately effective upon filing. Each neighbor below shares some of those properties but breaks at least one.
The MEF forms are the closest functional twins. They invoke the same Rule 462(b), share the same 20 percent cap, are limited to additional securities of the same class, and become effective immediately on filing. Issuers typically choose between them and POS462B during an upsize at or near pricing.
Distinction: form structure and file number. POS462B is styled as a post-effective amendment and keeps the file number of the underlying S-1/S-3/F-1/F-3. The MEF variants are freestanding new registration statements with their own file numbers that incorporate the prior registration by reference. The legal cap, immediate effectiveness, and same-class requirement are otherwise identical. To capture the full population of Rule 462(b) upsizes, pair POS462B with the four MEF datasets.
POS AM is the catch-all post-effective amendment for operating-company registration statements. Both POS AM and POS AMI amend an already-effective registration.
Distinctions: (1) POS AM is generally not immediately effective and is subject to staff review or Commission order; (2) POS AM has no 20 percent cap and no same-class limitation; (3) POS AM is used for substantive disclosure updates, Section 10(a)(3) annual updates, adding offerings, or registering different classes of securities. POS462B is the mechanical, immediately-effective, capped, same-class subset.
Rule 462(d) amendments are also immediately effective without staff review, matching POS462B on timing.
Distinction: purpose. Rule 462(d) cannot register additional securities. It is reserved for technical, non-substantive changes (adding exhibits, clerical corrections). POS462B expands the registered offering size; 462(d) preserves it.
POS EX is the operational sibling to Rule 462(d): a post-effective amendment whose sole purpose is to add exhibits to an effective registration.
Distinction: POS EX registers no new securities, has no cap, and is dominated by legal exhibits. POS462B includes exhibits (opinions, consents, fee table) only as supporting documentation for the share-count expansion that is its actual purpose.
POS AMI and POS 8C are post-effective amendments filed by investment companies and closed-end funds, respectively.
Distinction: filer population. Rule 462(b) and POS462B are operating-company instruments and do not apply to investment companies. POS AMI and POS 8C are useful only to confirm exclusion — any record in those datasets is, by definition, outside the POS462B population.
485APOS (delayed effective date) and 485BPOS (immediately effective) are the Rule 485 post-effective amendments used by open-end funds, variable insurance products, and other investment-company registrants on Forms N-1A, N-3, N-4, and N-6.
Distinction: 485BPOS shares the immediate-effectiveness feature with POS462B, but lives under Rule 485 rather than Rule 462, applies to a different filer population, and has no 20 percent same-class cap. There is no operating-company analog to 485BPOS, and no investment-company analog to POS462B; the two regimes are parallel, not overlapping.
The 424B family (424B1 through 424B8, 424A) supplements the prospectus of an already-effective registration with pricing, plan of distribution, takedown, or risk-factor updates. They are frequently filed in the same pricing window as a POS462B.
Distinction: 424B filings update prospectus content; they do not register additional securities. A POS462B can raise the share ceiling; a paired 424B then reflects the final priced terms. Reconstructing an upsized deal typically requires both.
These are the base registrations that POS462B amends. They contain the full prospectus, financial statements, risk factors, and Securities Act disclosure package and undergo staff review (or automatic effectiveness for WKSI shelves).
Distinction: scope and content. POS462B is a thin overlay incorporating the base by reference; it adds only the incremental share count, updated fee table, opinions, and consents. The substantive offering documentation lives in the base form (and any 424B), not in the POS462B.
RW (registration withdrawal) and AW (amendment withdrawal) remove filings from effectiveness or pending status.
Distinction: direction. RW and AW contract or terminate a registration; POS462B expands one. They share only the file-number lineage and are useful for assembling a full registration-statement history, not for identifying upsizes.
POS462B is uniquely identified by the conjunction of all five properties: post-effective amendment + Rule 462(b) immediate effectiveness + 20 percent same-class cap + operating-company issuer + adds new securities. Drop any one property and a different form takes over:
The POS462B dataset is therefore the cleanest signal for operating-company offerings upsized at or near pricing through the post-effective-amendment branch of Rule 462(b). It is not a substitute for the base prospectus (use S-1/S-3/F-1/F-3 plus 424B) and does not cover the freestanding MEF branch of Rule 462(b) (pair with the MEF datasets for a complete Rule 462(b) view).
The narrow mechanic of Form POS462B — additional securities of the same class, capped at 20 percent of the original maximum aggregate offering price, effective immediately on filing — concentrates the audience around pricing-day deal sizing, drafting precedent, and over-allotment tracking.
Used to flag IPOs and follow-ons that upsized at pricing or required incremental registration for green-shoe exercise. Bankers pull filedAt to align the amendment with the pricing date, entities to identify the issuer, and the fee calculation table for the additional shares and incremental aggregate offering price. The 333- file number ties the POS462B back to the underlying S-1 or S-3, letting them compute the percentage of the 20 percent headroom consumed. Output: upsize hit-rate analytics and league-table adjustments.
Used as a precedent library for drafting POS462B amendments. Counsel search prior filings for facing-page language, the Rule 462(b) recitation, legality opinions, and auditor consents tied to the additional securities. The fee calculation table and the underlying 333- reference are checked to verify 20 percent cap arithmetic and incorporation-by-reference wording. Output: first drafts, pricing-day filing checklists, and Rule 462(b) know-how.
Used to track over-allotment mechanics where the green-shoe pushes the deal beyond what the base registration covers. They compare filedAt against the underlying registration's effective date, read the incremental share count from the fee table, and confirm signatory authority. Output: closing checklists and post-closing reconciliation of gross deal size against registered shares.
Used as a structured signal of upsizing and green-shoe exercise. Analysts ingest accessionNo, filedAt, entities, and fee-table line items to compute the share of IPOs invoking Rule 462(b), the average uptake of the 20 percent cap, and sector or season patterns. Output: IPO calendar reconstruction and reports comparing filed, priced, and final allotted size.
Used both as sector precedent and to retrieve the company's own prior POS462B filings ahead of a new offering. They template from the facing page, incorporation-by-reference statement, signatures, and consent exhibits to shorten pricing-day turnaround.
Used to monitor compliance with the 20 percent ceiling and to study how Rule 462(b) is invoked across issuers. The fee calculation table and the 333- file number tying back to the parent registration are the critical fields for verifying that the incremental aggregate offering price stays within the statutory cap. Aggregated counts inform policy review of the immediate-effectiveness mechanic.
Used in empirical studies of IPO underpricing, over-allotment exercise, and deal upsizing. POS462B is a clean indicator of pricing-day demand exceeding the filed size. Researchers merge filedAt, entities, the fee table, and the linked underlying registration with pricing and aftermarket data to build panel datasets.
Used to attribute upsized deals to specific underwriting syndicates by cross-referencing entities and the underlying S-1 or S-3 (and its underwriting agreement exhibits). Output: pitch materials and benchmarking on which firms most often leave pricing headroom consumed via Rule 462(b).
Used to ingest POS462B as a discrete form type into filing warehouses. Engineers key off accessionNo, formTypes, filedAt, and documentFormatFiles to link each amendment to its parent registration accession via the 333- file number. The dataset also serves as a controlled corpus for fee-table parsing and incorporation-by-reference link resolution.
Build a panel of pricing-day upsizes by reading entities[].cik, entities[].tickers, and filedAt from metadata.json and joining each accession to its parent registration through entities[].fileNo (the underlying 333- number). Parse the incremental "amount being registered" and "proposed maximum aggregate offering price" out of the Calculation of Registration Fee table in the primary HTML, divide by the parent registration's original maximum aggregate offering price, and report the share of the 20 percent headroom consumed. Output: hit-rate dashboards of upsized IPOs by quarter, sector (entities[].sic), and lead underwriter.
Detect cases where the over-allotment option pushed gross deal size beyond what the base registration covered. Filter to additive 462(b) records (multi-document accessions carrying an EX-5.1 opinion entry in documentFormatFiles[]), align filedAt to the underlying offering's pricing 424B, and use the fee-table delta as the registered green-shoe top-up. Output: closing-checklist reconciliation between gross allotted size and registered share count, plus a clean signal for empirical studies of shoe exercise.
Search across primary POS462B HTML bodies for the Rule 462(b) recitation, incorporation-by-reference paragraph, Rule 478 short-form signature block, and matching EX-5.1 opinion and EX-23.1 consent exhibits. Filter precedents by entities[].stateOfIncorporation, entities[].sic, and underlying form type (recovered from the facing-page "POST-EFFECTIVE AMENDMENT NO. [N] TO FORM [S-1/S-3/F-1]" heading). Output: first-draft kits and pricing-day filing checklists keyed to comparable issuers.
Replay the statutory cap arithmetic across the dataset. For every additive record, extract the incremental aggregate offering price from the fee table, retrieve the parent registration's original maximum aggregate offering price via the fileNo lookup, and flag accessions where the incremental amount exceeds 20 percent. Output: an exception list for Commission staff review and an audit trail confirming that immediate effectiveness was properly invoked.
Isolate the deregistration flavor of POS462B by selecting accessions with a single document and no EX-5.1 / EX-23.1 entries in documentFormatFiles[], then key on the "DEREGISTRATION OF SECURITIES" subtitle and Rule 478 boilerplate in the body. Capture the recited triggering event (completed offering, merger closing, abandonment) and the file number being closed out. Output: a registration-statement lifecycle table that pairs each base S-1/S-3 with its eventual termination, useful for shelf-utilization studies and corporate-action histories.
Adjust final deal-size attributions for upsizes that occurred after the base registration. Join POS462B filedAt and fee-table increments to deal records from S-1/S-3 plus paired 424B prospectus supplements, then recompute gross proceeds per syndicate. Output: corrected league-table credits that reflect the priced and registered size rather than the originally filed amount.
Use POS462B as a clean indicator of demand exceeding filed size on the day of pricing. Researchers merge filedAt, entities[].cik, the fee-table top-up, and the parent 333- registration with CRSP/Compustat pricing and aftermarket data to study underpricing, allocation, and shoe exercise. Output: panel datasets where Rule 462(b) invocation is a binary or continuous (percentage of cap consumed) covariate.
Onboard POS462B as a discrete form type in an EDGAR pipeline. Engineers key on accessionNo, formType, and filedAt, traverse documentFormatFiles[] to materialize each .htm exhibit, and resolve incorporation-by-reference links by extracting the cover-page 333- number and joining back to the parent accession. The dataset doubles as a bounded corpus for training fee-table extractors, since the Calculation of Registration Fee table appears in a stable position on every additive filing.
The Form POS462B Files Dataset is available through three access methods: a dataset index JSON API for metadata and container enumeration, a single archive download for the entire dataset, and individual container downloads for incremental retrieval.
Dataset Index JSON API: https://api.sec-api.io/datasets/form-pos462b-files.json
This endpoint returns dataset-level metadata along with the list of all available container files. It does not require an API key. The response includes the dataset name, description, last update timestamp, earliest sample date (1995-07-01), total record count, total size, form types covered (POS462B), the container format (ZIP), and the file types contained within each container (TXT, JSON, HTML). Each container entry includes its download URL, object key, size, record count, and last updated timestamp. Use this endpoint to monitor which containers were refreshed in the most recent run and to decide which ones to fetch on a daily basis.
Example JSON response:
1
{
2
"datasetId": "1f13365b-9ae0-69e6-ba7e-60ec4605dc4b",
3
"datasetDownloadUrl": "https://api.sec-api.io/datasets/form-pos462b-files.zip",
4
"name": "Form POS462B Files Dataset",
5
"description": "Form POS462B filings are post-effective amendments to registration statements filed pursuant to Rule 462(b) under the Securities Act of 1933.",
6
"updatedAt": "2026-04-15T18:10:31.024Z",
7
"earliestSampleDate": "1995-07-01",
8
"totalRecords": 634,
9
"totalSize": 2994806,
10
"formTypes": ["POS462B"],
11
"containerFormat": "ZIP",
12
"fileTypes": ["TXT", "JSON", "HTML"],
13
"containers": [
14
{
15
"downloadUrl": "https://api.sec-api.io/datasets/form-pos462b-files/2026/2026-03.zip",
16
"key": "2026/2026-03.zip",
17
"size": 13818783,
18
"records": 154,
19
"updatedAt": "2026-03-21T02:51:19.000Z"
20
}
21
]
22
}
Download Entire Dataset: https://api.sec-api.io/datasets/form-pos462b-files.zip?token=YOUR_API_KEY
Downloads the full dataset as a single ZIP archive containing all POS462B filing files since 1995. This endpoint requires an API key passed via the token query parameter.
Download Single Container: https://api.sec-api.io/datasets/form-pos462b-files/2026/2026-03.zip?token=YOUR_API_KEY
Downloads one monthly container ZIP file instead of the full dataset. Container paths follow the YYYY/YYYY-MM.zip convention and are listed in the dataset index JSON. This endpoint requires an API key.
To enumerate and fetch containers programmatically, retrieve the dataset index, iterate over the containers array, and download each downloadUrl with your API key appended.
Python example:
1
import requests
2
3
API_KEY = "YOUR_API_KEY"
4
INDEX_URL = "https://api.sec-api.io/datasets/form-pos462b-files.json"
5
6
index = requests.get(INDEX_URL).json()
7
8
for container in index["containers"]:
9
url = f"{container['downloadUrl']}?token={API_KEY}"
10
response = requests.get(url)
11
filename = container["key"].replace("/", "_")
12
with open(filename, "wb") as f:
13
f.write(response.content)
14
print(f"Downloaded {container['key']} ({container['records']} records)")
Bash example using curl and jq:
1
API_KEY="YOUR_API_KEY"
2
curl -s https://api.sec-api.io/datasets/form-pos462b-files.json \
3
| jq -r '.containers[].downloadUrl' \
4
| while read url; do
5
curl -O "${url}?token=${API_KEY}"
6
done
The dataset covers EDGAR form type POS462B — post-effective amendments to registration statements filed pursuant to Rule 462(b) of the Securities Act of 1933. Both flavors of POS462B accession appear: additive 462(b) registrations that add new securities of the same class, and deregistration/termination amendments that close out unsold securities on a prior 462(b)-related registration.
One record is one complete EDGAR submission — one accession — for a POS462B filing. The record unit is the accession, not the EDGAR filing-index page and not an individual exhibit; every document the registrant submitted under that accession number (other than image binaries) is included, alongside a parsed metadata.json header.
The form is filed by the issuer/registrant that already has an effective Securities Act registration statement, typically domestic operating companies pricing an IPO or follow-on off Form S-1 or S-3, foreign private issuers on F-1 or F-3, and real estate or similar issuers on S-11. Investment companies do not use POS462B; 1940 Act registrants file under the Rule 485 regime (485APOS, 485BPOS) instead.
The filing is event-driven and tied to pricing. It is transmitted to EDGAR no later than the date of first sale of the additional securities, and in practice is filed the evening of pricing or in the early hours after pricing, almost always concurrently with the Rule 424(b) prospectus supplement for the deal. The filing is immediately effective on acceptance, with no Staff review or acceleration request.
The dataset covers all POS462B accessions on EDGAR from July 1995 (the inception of mandatory EDGAR filing) through the present, with the earliest sample dated 1995-07-01. Volume is modest because Rule 462(b) is itself narrow.
Each accession folder contains a metadata.json header (always present), the SGML-wrapped .htm/.html submission documents the registrant filed, and, where present, the EDGAR complete-submission .txt concatenation. Containers are distributed as monthly ZIPs named YYYY-MM.zip. Image attachments (.jpg, .gif) and XBRL files are deliberately excluded.
The MEF forms are the closest functional twins: they invoke the same Rule 462(b), share the same 20 percent cap, are limited to additional securities of the same class, and are immediately effective. The structural difference is that POS462B is styled as a post-effective amendment and keeps the file number of the underlying S-1/S-3/F-1/F-3, while the MEF variants are freestanding new registration statements with their own 333- file numbers. To capture the full population of Rule 462(b) upsizes, pair this dataset with the four MEF datasets.
The form-type code alone does not distinguish them — both carry formType: "POS462B". The flavor can be inferred from the document count in documentFormatFiles[]: additive records are multi-document and typically include EX-5.1 (legality opinion) and EX-23.1 (auditor consent) entries plus a Calculation of Registration Fee table in the body, while deregistration records are usually single-document, carry no exhibits, and contain a "DEREGISTRATION OF SECURITIES" explanatory note in the primary HTML body.