Form U-6B-2 Files Dataset

The Form U-6B-2 Files Dataset is a closed historical archive of EDGAR submissions of Form U-6B-2 ("Certificate of Notification") and its amendment variant Form U-6B-2/A, filed by registered holding companies and their subsidiaries under the Public Utility Holding Company Act of 1935 (PUHCA 1935). Each record corresponds to a single accession-number-level filing in which the filer notified the SEC, after the fact, of a security issued, renewed, or guaranteed under the Section 6(b) statutory exemption — a transaction that was neither pre-cleared on a Form U-1 declaration nor swept into the Rule U-48 short-term borrowing exemption. The dataset begins with the start of EDGAR PUHCA coverage in January 1994 and closes in February 2006, when the Energy Policy Act of 2005 repealed PUHCA 1935 and discontinued the form. Records are delivered as monthly ZIP archives, one accession folder per filing, packaging a structured metadata.json alongside the original certificate body document and any non-image exhibits preserved from the EDGAR submission.

Dataset APIs

Dataset Files

What This Dataset Contains

The dataset captures every EDGAR-era Form U-6B-2 and Form U-6B-2/A submission accepted by the SEC between January 1994 and the form's discontinuation in February 2006. Form U-6B-2 was a "Certificate of Notification" filed pursuant to Rule 20(d) — formerly Rule 52 — of PUHCA 1935. Its purpose was narrow and procedural: a registered holding company or a filing subsidiary notified the SEC that it had issued, renewed, or guaranteed a security under the Section 6(b) exemption when the transaction was neither the subject of a Form U-1 declaration nor covered by the Rule U-48 exemption. The form was therefore a post-transaction certificate rather than an application or declaration; its informational role was to report the terms of an exempt securities transaction in a fixed, lightly-tabular nine-item template, accompanied by a signed certification by an officer of the issuing entity.

The U-6B-2/A variant carries the same nine-item structure and is used solely to amend a previously filed certificate; structurally and in dataset packaging it is indistinguishable from a fresh U-6B-2 except for the form-type label and amendment-mentioning description. Because PUHCA 1935 was repealed by the Energy Policy Act of 2005 effective February 8, 2006, the dataset is closed: no new records can arise after that date, and the corpus represents the complete EDGAR-era public record of Section 6(b)-exempt securities activity within registered holding-company systems. Filings are distributed as monthly ZIP archives keyed by <year>/<year>-<month>.zip; supported file types within an accession folder include TXT, JSON, HTML, and PDF.

Content Structure of a Single Record

What one record represents

One record in the Form U-6B-2 Files Dataset corresponds to a single EDGAR submission of Form U-6B-2 or its amendment variant Form U-6B-2/A — that is, one accession-number-level filing made by a registered holding company or one of its subsidiaries under PUHCA 1935. The record is materialized as one folder named with the EDGAR accession number stripped of dashes (an 18-digit string such as 000005447605000005, which corresponds to canonical accession 0000054476-05-000005). Each accession folder always contains a metadata.json describing the submission and one or more original document files preserved from the EDGAR submission (the certificate body and any non-image attachments).

Container and per-record layout

The dataset is delivered as monthly ZIP archives keyed by <year>/<year>-<month>.zip. Each ZIP decompresses to a directory <year>-<month>/ containing one subdirectory per filing, named with the un-dashed 18-digit accession number. Inside each accession folder are exactly two kinds of artifacts: a metadata.json describing the EDGAR submission, and the original document files that constituted the submission body, less any image exhibits. Most U-6B-2 records have a single body document plus the metadata file; a minority include additional non-image attachments such as PDF exhibits. The accession folder is the unit a downstream consumer iterates over.

A subtle joining quirk is that the folder name uses the un-dashed accession form while metadata.json.accessionNo carries the canonical dashed form (e.g. folder 000005447605000005 versus field "0000054476-05-000005"); consumers correlating folders to metadata must normalize between the two.

metadata.json shape

metadata.json is a flat JSON object describing one EDGAR submission. The fields present in a U-6B-2 record are:

• formType — "U-6B-2" for fresh certificates or "U-6B-2/A" for amendments.
• accessionNo — canonical dashed accession identifier (e.g. "0000054476-05-000005").
• description — the EDGAR submission-type description, typically "Form U-6B-2 - Notification of security issue, renewal or guaranty [Rule 20(d)]".
• filedAt — ISO-8601 timestamp with timezone offset capturing the EDGAR acceptance moment (e.g. "2005-09-12T10:01:26-04:00").
• linkToFilingDetails — URL to the primary document on EDGAR.
• linkToTxt — URL to the complete .txt submission bundle on EDGAR.
• linkToHtml — URL to the EDGAR -index.htm page for the filing.
• linkToXbrl — empty string in this dataset.
• id — opaque 32-character hex hash used as an internal record identifier.
• documentFormatFiles[] — array of document descriptors; see below.
• dataFiles[] — empty array in this dataset.
• entities[] — array of one or more filer-entity objects.

Each entity object in entities[] carries companyName (suffixed by the EDGAR role marker, e.g. "... (Filer)"), cik, irsNo, fileNo, filmNo, act, type, sic, stateOfIncorporation, and fiscalYearEnd (in MMDD form). Two PUHCA-specific values are diagnostic: act is "35" (Public Utility Holding Company Act of 1935) and fileNo is prefixed 040- (the PUHCA file-number range, e.g. "040-00545"). These two fields do not appear in mainstream Securities Act / Exchange Act EDGAR datasets and are reliable filters for PUHCA-regime filings. Many filings list multiple entities — typically a parent registered holding company plus one or more subsidiary issuers — each as its own object in the array.

documentFormatFiles[] always contains at least two entries. The first describes the primary document with sequence "1", a type matching the form ("U-6B-2" or "U-6B-2/A"), a filer-chosen description, a size in bytes encoded as a string, and a documentUrl pointing back to EDGAR. The second is a sentinel entry describing the complete .txt submission bundle: both its sequence and type are a single space " ", and its documentUrl matches linkToTxt. The .txt submission bundle itself is not materialized inside the accession folder — only the primary document (and any non-image exhibits) is — but the second documentFormatFiles entry preserves a pointer to it on EDGAR. When additional non-image exhibits accompany the certificate, they appear as further entries in the array with their own sequence numbers.

Body document and the nine-item U-6B-2 template

Each body document is wrapped in EDGAR's SGML document envelope:

          1
          <DOCUMENT>
        

          2
          <TYPE>U-6B-2
        

          3
          <SEQUENCE>1
        

          4
          <FILENAME>...
        

          5
          <DESCRIPTION>...
        

          6
          <TEXT>
        

          7
          ... certificate body (HTML or ASCII) ...
        

          8
          </TEXT>
        

          9
          </DOCUMENT>
        

Filenames are filer-chosen and unenforced; observed examples include kcpl_u6b2090905.htm, form_u6b-2.htm, and formu6b2.txt. The certificate body itself follows a fixed nine-item template that did not change across the form's twelve-year EDGAR life. The items are:

1. Type of securities — a narrative description of the security or securities being notified. Common subjects are first-mortgage bonds, environmental improvement revenue refunding bonds, pollution control revenue bonds, intercompany notes, commercial paper, guarantees of subsidiary obligations, and short-term credit-facility borrowings. Multiple distinct securities can be listed within one certificate, each enumerated separately.
2. Issue, renewal or guaranty — a one-word classification of the transaction (Issue., Renewal., or Guaranty.).
3. Principal amount of each security — face/principal amount per instrument, frequently dollar-denominated and stated as an exact figure rather than rounded.
4. Rate of interest per annum — fixed coupon, floating-rate formula, tiered or stepped rates, or reset provisions tied to an underlying indenture or credit agreement.
5. Date of issue, renewal or guaranty — calendar date the transaction took effect.
6. If renewal of security, give date of original issue — populated only for renewal transactions, citing the original issuance date(s); blank or marked not-applicable otherwise.
7. Date of maturity of each security — stated maturity date or, for serial issues, the schedule of maturities.
8. Name of person to whom issued, renewed or guaranteed — counterparty identification: typically an indenture trustee, a specific institutional purchaser, "the public", or, in intercompany transactions, an affiliate by name.
9. Consideration, collateral, and authorization — narrative section combining the consideration received, any collateral or guarantees, the use of proceeds, references to the authorizing board resolution, and the certifying officer's signature block (typed name, title, and date). The certification of exemption under Section 6(b) of PUHCA is conveyed in this final item and through the form's heading.

The text is generally short — most certificates run to a few HTML pages — and typically mixes brief narrative for items 1, 8, and 9 with terse single-value entries for items 2 through 7.

Included content

Each record packages: the metadata.json describing the submission; the primary U-6B-2 (or U-6B-2/A) certificate document in its native EDGAR form (HTML, plain ASCII text, or, occasionally, PDF); and any non-image exhibits or attachments that were part of the original submission, each preserved with its own SGML document wrapper, sequence number, and filename. The metadata captures filer identity (CIK, IRS number, SIC, state of incorporation, fiscal year end), filing identifiers (accession, file number, film number, form type), the EDGAR acceptance timestamp, EDGAR URLs back to the live filing, and a per-document descriptor list with byte-size and EDGAR-side URLs.

Excluded or separate content

Image files from the original EDGAR submission (typically GIF or JPG exhibits used for graphics, signatures, or scanned attachments) are excluded from the dataset packaging. The complete .txt submission bundle is referenced via linkToTxt and via a sentinel entry in documentFormatFiles[] but is not materialized inside the accession folder; only the primary document and any non-image exhibits are present locally. The full EDGAR header SGML (the <SEC-HEADER> block that precedes <DOCUMENT> envelopes in the original submission) is not preserved as a separate file inside the accession folder; the structured equivalents of those header fields are captured in metadata.json.

Format evolution across the U-6B-2 era

The body-document file format evolved during the form's active life, while the nine-item template itself remained fixed. Filings from 1994 through roughly the early 2000s are typically delivered as plain ASCII .txt documents — fixed-width text with hard line breaks, in keeping with the early-EDGAR convention of ASCII-only submissions. From approximately 2002 onward, filers transitioned to HTML body documents, still wrapped in the same <DOCUMENT>...</DOCUMENT> SGML envelope but with the inner <TEXT> block containing HTML markup rather than plain text. These HTML files are frequently HTML 3.2-style output produced by Microsoft Word, often retaining generator meta tags and even absolute Windows paths in <META NAME="Template"> headers — useful as forensic signals about authoring origin but not as structured fields. Some later filings additionally include .pdf exhibits as supplementary attachments. Because the underlying form requirements were fixed by the PUHCA rule and the SEC form template did not change before discontinuation, the substantive disclosure content (the nine numbered items) is consistent across both the ASCII and HTML eras; only presentation and authoring tooling shifted.

Interpretation notes

Several quirks matter for extraction and analysis:

• Accession-key normalization. The accession-folder name uses the un-dashed 18-digit form while metadata.json.accessionNo is dashed; any join between the folder layer and the metadata layer must normalize between them.
• Sentinel documentFormatFiles[] entry. The array always carries an entry whose sequence and type are a single space and which points to a .txt submission bundle that is not present locally; downstream code should treat whitespace-typed entries as remote references rather than as local files.
• PUHCA filters. act = "35" and the 040- fileNo prefix are reliable signals for isolating PUHCA-regime filings and for distinguishing them from same-named entities' filings made under other Acts.
• U-6B-2/A amendments. Amendments share the folder and JSON shape of fresh U-6B-2 filings; only formType and the wording of description differentiate them, and the body document continues to follow the same nine-item template (often restating only the changed item value).
• Multiple co-filers. The entities[] array is the authoritative source of filer identity and frequently lists multiple co-filers (a parent registered holding company plus one or more subsidiary issuers); records joining filings to issuers should iterate the entire array rather than assume a single filer per record.
• Heading-anchored extraction. Because the certificate body is short and highly templated, most useful structured fields — security type, principal amount, interest rate, transaction date, maturity, counterparty, signing officer — can be extracted by mapping to the nine numbered headings. Filer-side variation in HTML markup, item-numbering punctuation, and inline narrative within items 1 and 9 means heading-anchored parsing is more reliable than rigid positional or fixed-offset parsing.
• Multi-security certificates. A single filing frequently notifies more than one security at once; items 3, 4, 6, and 7 may carry parallel lists rather than single values, and downstream extraction should expect arrays per item rather than scalars.

Who Files or Publishes This Dataset, and When

Who files or discloses the record

Form U-6B-2 was a certificate of notification filed with the SEC by entities inside a registered holding-company system under PUHCA 1935. The filing population was narrow and sector-specific:

• Registered holding companies under PUHCA 1935. Corporations that owned or controlled, directly or indirectly, 10 percent or more of the voting securities of a public-utility company or another holding company, and that had registered with the SEC under Section 5 because they did not qualify for a Section 3 exemption.
• Subsidiaries of registered holding companies. Operating electric and gas utilities, intermediate holding-company subsidiaries, Section 13 service companies, and certain non-utility subsidiaries within a registered system. Where the issuance, renewal, or guarantee occurred at the subsidiary level, the subsidiary was the filer and typically named its parent in the certificate.

Each accession number is either an original Form U-6B-2 or an amendment on Form U-6B-2/A, filed by the same entity that submitted the original certificate.

When the record is created or required

Form U-6B-2 was an event-driven, post-transaction certificate, not a periodic report. It was triggered when a registered holding company or its subsidiary issued, renewed, or guaranteed a security in reliance on the exemption in Section 6(b) of PUHCA 1935, where the transaction was:

1. not the subject of a Form U-1 declaration filed in advance to obtain a Commission order, and
2. not covered by the blanket short-term-borrowing exemption in Rule U-48.

The certificate was filed promptly after the transaction under Rule 52 (the operative rule prescribing Form U-6B-2 for Section 6(b) notifications). A single certificate could cover a single transaction date or a batched reporting period, typically a calendar month, depending on the filer's practice. There was no annual or quarterly deadline; volume in the dataset reflects underlying transaction activity in registered systems.

EDGAR began accepting PUHCA filings in January 1994, so the digital dataset starts there. Earlier paper certificates dating from the late 1930s onward exist in Commission records but are outside the EDGAR-derived dataset.

The reporting regime ended by statute. The Energy Policy Act of 2005 (Pub. L. 109-58, enacted August 8, 2005) repealed PUHCA 1935 effective February 8, 2006, replacing it with PUHCA 2005, which is administered by the Federal Energy Regulatory Commission rather than the SEC. With the repeal of Sections 5, 6, and 7, Section 6(b) and Rule 52 ceased to operate and Form U-6B-2 was discontinued. The dataset is closed; the latest filings cluster in early 2006 around the repeal's effective date.

U-6B-2 and U-6B-2/A relationship

Form U-6B-2/A records are amendments to previously filed Form U-6B-2 certificates, submitted by the same filer to correct or supplement the original — for example, revising tabular security descriptions, correcting issuer identification, restating principal amounts, or adding omitted transactions to a covered period. Amendments do not re-trigger or re-authorize the underlying transaction; the Section 6(b) exemption analysis is unchanged, and the amendment simply updates the post-transaction record before the Commission.

Important distinctions

• Form U-6B-2 vs. Form U-1. Form U-1 was a declaration filed in advance to obtain Commission authorization for a transaction. Form U-6B-2 was a post-transaction certificate stating that no such order was needed because the Section 6(b) exemption applied. The two are mutually exclusive for any given transaction.
• Form U-6B-2 vs. Rule U-48 short-term borrowings. Short-term notes and similar instruments falling within Rule U-48's blanket exemption did not require a Form U-6B-2 certificate, so this class of exempt transaction is systematically absent from the dataset.
• Form U-6B-2 vs. 1933/1934 Act filings. Form U-6B-2 was a PUHCA-specific certificate, not a registration statement, prospectus, or periodic report. A registered holding company that was also an Exchange Act reporting issuer continued to file S-series registration statements, 10-K, 10-Q, and 8-K separately.
• Filer vs. parent identification. Where a subsidiary issued the security, the subsidiary was the filer even though the parent registered holding company is named in the certificate and is the entity whose registered status brings the system within the regime.
• Exempt holding companies. Holding companies exempt under Section 3 of PUHCA 1935 — typically Section 3(a)(1) intrastate holding companies and Section 3(a)(2) predominantly non-utility holding companies — generally did not file Form U-6B-2, because the Rule 52 certification regime was tied to registered status. Investor-owned utilities outside any registered system, municipal utilities, cooperatives, and federal power agencies were outside PUHCA 1935 reporting entirely.
• Post-February 2006 transactions. No Form U-6B-2 obligation arose for issuances, renewals, or guarantees occurring after the repeal took effect; oversight of holding-company activity moved to FERC under PUHCA 2005 and to state public utility commissions.

How This Dataset Differs From Similar Datasets or Filings

Form U-6B-2 sits inside the now-repealed PUHCA 1935 filing family. The most useful comparisons are to the other PUHCA forms that surrounded the same financing transactions, the certificate mechanics that complemented them, the Securities Act regime that sometimes applied to the same securities, and the FERC successor regime that absorbed financing oversight after 2005.

Form U-1 (Declaration as to Securities Transactions)

U-1 was the principal pre-transaction declaration filed by registered holding companies seeking SEC authorization for securities issuances, acquisitions, dividends, or reorganizations under Sections 6, 7, 9, 10, and 12. It is the closest sibling of U-6B-2 because both concerned issuances by registered systems, but they are mutually exclusive by design. U-1 is a pre-approval declaration that triggered SEC review, public notice, hearings, and an order; it carried prospectus-style economics, capitalization tables, use-of-proceeds narratives, and exhibits. U-6B-2 is a post-issuance, tabular certificate filed only when the issuance proceeded under the self-executing Section 6(b) exemption and was therefore not the subject of any U-1.

Form U5S (Annual Report of Registered Holding Companies)

U5S was the comprehensive annual report covering system structure, intercompany transactions, service-company allocations, and full-year financing activity. Section 6(b)-exempt issuances reported on U-6B-2 ultimately rolled into the U5S financing picture. The difference is cadence and granularity: U5S is annual, system-wide, and aggregated; U-6B-2 is transaction-level, event-driven, and filed promptly after each exempt issuance. Use U5S for the consolidated annual footprint; use U-6B-2 to isolate the precise terms of an individual exempt security at issuance.

Form U-9C-3

U-9C-3 was a quarterly certificate of notification covering specified exempt transactions, primarily fuel, energy, and intra-system arrangements under Rule 87 and related rules. Like U-6B-2, it is a post-event tabular certificate rather than a pre-approval declaration. The distinction is subject matter: U-9C-3 reports exempt energy and intra-system service transactions; U-6B-2 reports exempt securities issuances under Section 6(b).

Rule U-48 Short-Term Borrowing Exemption

Rule U-48 exempted certain short-term unsecured subsidiary borrowings from the declaration requirement, subject to limits and conditions, and produced no dedicated EDGAR form. U-6B-2 and U-48 are disjoint: U-6B-2 was required precisely when a Section 6(b)-exempt issuance fell outside the U-48 short-term safe harbor. The U-6B-2 dataset therefore captures the exempt-issuance slice that U-48 did not absorb.

Form 35-CERT (Certificate Filings under PUHCA Orders)

35-CERT was used by registered holding companies to certify compliance with conditions in an existing SEC order, typically following a U-1 authorization. Both 35-CERT and U-6B-2 are post-event EDGAR certificates, but they sit on opposite sides of the order/exemption split: 35-CERT certifies compliance with an SEC-approved transaction; U-6B-2 notifies the Commission of a transaction that proceeded entirely outside the order process under a statutory exemption. A given transaction generates one or the other, not both.

Securities Act Registration Filings (Form S-1, S-3)

Form S-1 and Form S-3 are Securities Act registration statements for public offerings, including those by utility holding companies and their subsidiaries. They are prospectus-grade, narrative, audited, and investor-facing, with risk factors, financial statements, and use-of-proceeds discussion. U-6B-2 is a one- or two-page tabular certificate addressed to the SEC's PUHCA function. The two regimes frequently apply to non-overlapping transactions, since many U-6B-2 issuances were private placements, intra-system, or otherwise exempt from Securities Act registration; when both apply to the same deal, they capture entirely different facets.

FERC Form 1 and Form 715 (Post-2005 Successor Oversight)

After the Energy Policy Act of 2005 repealed PUHCA 1935, financing oversight for utility holding company systems shifted to FERC under PUHCA 2005 and Sections 203/204 of the Federal Power Act. FERC Form 1 (annual financial and operating report) and Form 715 (annual transmission planning report) are the closest functional successors to the system-level oversight role PUHCA filings once played. They are filed at FERC, not the SEC, on different schemas, and they are periodic and system-level rather than transaction-level. They do not reproduce the discrete exempt-issuance record that U-6B-2 provided.

Boundary summary

Form U-6B-2 is uniquely a post-issuance, transaction-level, tabular certificate of notification for securities issued, renewed, or guaranteed under the Section 6(b) statutory exemption of PUHCA 1935, filed only when neither a U-1 declaration nor the Rule U-48 short-term borrowing exemption applied. It does not contain pre-approval analysis (see U-1), system-wide annual context (see U5S), order-compliance certification (see 35-CERT), exempt energy/intra-system reporting (see U-9C-3), investor-facing prospectus detail (see S-1, S-3), or post-2005 successor oversight data (see FERC Form 1 and Form 715). No other dataset substitutes for its specific function: a contemporaneous, transaction-by-transaction record of Section 6(b)-exempt securities activity within registered holding company systems from 1994 through the form's discontinuation in February 2006.

Who Uses This Dataset

The Form U-6B-2 Files Dataset is used wherever a closed 1994–2006 record of Section 6(b)-exempt financings by registered utility holding companies under PUHCA 1935 is the authoritative primary source. Different professionals pull different fields from the certificate of notification.

PUHCA-era utility and securities counsel

Lawyers handling legacy questions, grandfathered orders, surviving covenants, or successor-regime obligations use the filings to confirm which securities a former registered subsidiary issued, renewed, or guaranteed. They extract the exemption rationale, filing-subsidiary identity, security type, and renewal/guarantee status to build a documented chain of regulatory authority for indentures, opinion letters, and post-repeal compliance memoranda.

Fixed-income credit analysts on legacy utility paper

Analysts at insurers, separately managed accounts, and bank treasury desks holding long-dated utility debt reconstruct issuance histories of bonds, notes, debentures, preferred stock, and intercompany obligations. They extract issuer and guarantor names, principal, coupon, maturity, and renewal entries, then join to modern indenture data and successor-entity disclosures for recovery analysis, structural-subordination assessment, and detection of cross-guarantees still encumbering operating utilities.

M&A diligence teams on utility and transmission assets

Teams evaluating acquisitions of utilities, transmission assets, or holding-company successors use U-6B-2 records to surface legacy financings that may carry forward as assumed debt, contingent guarantees, or unresolved intercompany obligations. They focus on security descriptions, the issuing subsidiary, principal at issuance, and guarantee chains across sister subsidiaries to populate legacy-obligation schedules feeding purchase-price adjustments, R&W drafting, and disclosure schedules.

Litigation support and expert witnesses

Experts in utility ratemaking, securities litigation involving former holding companies, and successor-liability disputes cite the certification, security terms, and exemption rationale as primary evidence of what was disclosed to the SEC and when. The dataset supports expert reports, rebuttal exhibits, and discovery requests tied to specific accession numbers.

Energy regulator research staff

Economists and analysts at federal and state energy commissions use U-6B-2 to fill gaps left by Form U-1 and U5S filings when researching long-run utility cost of capital, intra-system money pools, and subsidiary-level borrowing. They extract issuance volumes, coupons, and maturities to support ratemaking precedent, prudence reviews, and historical capital-cost benchmarking.

Forensic accountants and successor-liability investigators

Accountants reconstructing historical capital structures of defunct or absorbed utility subsidiaries use U-6B-2 certificates to find securities absent from modern issuer disclosures. They pull issue date, principal, coupon, maturity, and guarantor identity to trace funds through intra-system money pools and document obligations that migrated to surviving entities after PUHCA repeal.

Academic researchers in regulatory and financial economics

Academics studying registered holding-company structure, PUHCA financing supervision, and Section 6(b) cost-of-capital effects use the dataset as a 1994–2006 panel. They aggregate principal by subsidiary, security type, and year, then pair with rate-base data and interest-rate series for peer-reviewed work on regulated-utility financing behavior.

Data engineers and historical-EDGAR archivists

Engineers building structured pre-repeal utility-financing datasets parse issuer and subsidiary names, security type, principal, coupon, maturity, issue date, and exemption rationale across the heterogeneous tabular content, then cross-join U-6B-2 to related U-1 declarations and U5S annual reports from the same holding company. The output is a normalized longitudinal financing database for analytics and retrieval.

RAG and LLM developers on historical-finance corpora

Teams building retrieval systems over historical SEC filings ingest U-6B-2 text and tables to enable QA over PUHCA-era exempt financings. The certification language, security descriptions, and subsidiary identifiers serve as retrieval targets, and the bounded 1994–2006 window functions as a closed evaluation corpus for domain-specific extraction.

Specific Use Cases

The Form U-6B-2 Files Dataset supports a small number of well-defined workflows that depend on the certificate's nine-item template and on the PUHCA-specific metadata (act = "35", 040- fileNo prefix, multi-entity entities[] arrays). The use cases below name the workflow, the fields used, and the output produced.

Reconstructing pre-2006 exempt-issuance histories for a registered holding-company system

Filter the dataset by entities[].cik for the parent registered holding company and each of its PUHCA-era subsidiaries, then sort accession folders by filedAt. Extract Items 1, 3, 4, 5, and 7 from the certificate body (security type, principal, coupon, issue date, maturity) and Item 2 to label each row as Issue / Renewal / Guaranty. The output is a per-system, per-subsidiary chronological table of every Section 6(b)-exempt issuance from 1994 through February 2006, used to fill the gap left by the absence of a single PUHCA-era issuance ledger.

Building a structured bond and note terms database for legacy operating companies

Parse Items 1, 3, 4, 7, and 8 across all U-6B-2 and U-6B-2/A filings to populate a normalized table keyed on issuer CIK, security type (first-mortgage bonds, pollution-control revenue bonds, intercompany notes, commercial paper), principal, coupon, maturity, and trustee or counterparty. Use heading-anchored extraction and expand multi-security certificates into one row per security. The resulting database feeds indenture-tracking systems, recovery models on long-dated utility paper, and structural-subordination analysis for insurers and bank treasuries still holding legacy obligations.

Cross-form joining of U-6B-2 to U-1 declarations and U5S annual reports

Use entities[].cik and fileNo (the 040- PUHCA range) to join U-6B-2 records to the same filer's U-1 declarations and U5S annual reports for the surrounding period. Reconcile the system-wide financing totals reported on U5S against the sum of Item 3 principal amounts across that year's U-6B-2 filings to identify exempt-issuance volume that did not pass through U-1 review. The output is a per-issuer reconciliation report distinguishing pre-approved (U-1), exempt-and-certified (U-6B-2), and short-term-exempt (Rule U-48) financing channels.

M&A diligence on legacy obligations of merged or absorbed utilities

For a target utility or its predecessor entities, pull every U-6B-2 record where the target appears in entities[], then extract Items 1, 3, 7, 8, and 9 to surface assumed debt, intercompany notes, and cross-guarantees among sister subsidiaries. Item 9's narrative on consideration, collateral, and authorizing board resolution is mined for guarantee language and use-of-proceeds detail. The deliverable is a legacy-obligation schedule feeding purchase-price adjustments, representations and warranties drafting, and disclosure schedules for transactions involving holding-company successors.

Mapping intercompany money-pool and guarantee networks

Identify Item 8 counterparties that are affiliates rather than third-party trustees or institutional purchasers, and pair them with Item 2 entries flagged Guaranty. and Item 1 descriptions of intercompany notes. Build a directed graph of issuer to guarantor or affiliated lender across the system, weighted by Item 3 principal. Forensic accountants and successor-liability investigators use the graph to trace funds through intra-system money pools and to document guarantees that migrated to surviving entities after PUHCA repeal.

Closed-corpus retrieval and extraction benchmark for PUHCA-era filings

Treat the 1994 to February 2006 U-6B-2 and U-6B-2/A submissions as a fixed evaluation corpus for retrieval and structured-extraction systems. The nine-item template provides ground-truth slots (security type, principal, coupon, maturity, counterparty, signing officer) for benchmarking heading-anchored parsers across both ASCII-era and HTML-era body documents. Useful for measuring extraction accuracy on heterogeneous filer-side markup and for tuning retrieval indices on certification language and subsidiary identifiers.

Dataset Access

The Form U-6B-2 Files Dataset is a closed historical dataset covering filings from 1994 through 2006. Because the filing program ended in 2006, the dataset is no longer updated and can be retrieved in full once and used offline. Authentication for downloads is handled via an SEC API key, passed either through the Authorization HTTP header or the ?token=YOUR_API_KEY query parameter.

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

This endpoint returns dataset-level metadata (name, last updated date, earliest sample date, total records, total size, form types covered, container format, and file types) along with the full list of monthly ZIP containers. Each container entry includes its key, size, records, updatedAt timestamp, and a direct downloadUrl. Since this dataset is closed, the container list is stable, but the same endpoint is used to discover all available monthly archives. This endpoint does not require an API key.

          1
          {
        

          2
            "datasetId": "1f13365b-9ae0-6998-8043-81ee43ce5a27",
        

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

          4
            "name": "Form U-6B-2 Files Dataset",
        

          5
            "updatedAt": "2006-12-29T17:42:11.000Z",
        

          6
            "earliestSampleDate": "1994-01-03",
        

          7
            "totalRecords": 1547,
        

          8
            "totalSize": 5691058,
        

          9
            "formTypes": ["U-6B-2", "U-6B-2/A"],
        

          10
            "containerFormat": "ZIP",
        

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

          12
            "containers": [
        

          13
              {
        

          14
                "downloadUrl": "https://api.sec-api.io/datasets/form-u6b2-files/2006/2006-12.zip",
        

          15
                "key": "2006/2006-12.zip",
        

          16
                "size": 41238,
        

          17
                "records": 11,
        

          18
                "updatedAt": "2006-12-29T17:42:11.000Z"
        

          19
              }
        

          20
            ]
        

          21
          }
        

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

Downloads a single consolidated ZIP archive containing every monthly container for the full 1994–2006 range. This is the recommended option for this dataset since it is closed and small enough to retrieve in one request. This endpoint requires an API key.

Download Single Container: https://api.sec-api.io/datasets/form-u6b2-files/2006/2006-12.zip?token=YOUR_API_KEY

Downloads one monthly container archive at <year>/<year>-<month>.zip, using the per-container downloadUrl returned by the index API. Use this when you only need filings from a specific month rather than the entire historical range. This endpoint requires an API key.

Frequently Asked Questions

What form does this dataset cover?

The dataset covers Form U-6B-2 ("Certificate of Notification") and its amendment variant Form U-6B-2/A, filed under Rule 20(d) — formerly Rule 52 — of the Public Utility Holding Company Act of 1935. It is the post-transaction certificate used by registered holding-company systems to notify the SEC of securities issued, renewed, or guaranteed under the Section 6(b) statutory exemption.

What does one record in this dataset represent?

One record corresponds to a single EDGAR accession-number-level submission of Form U-6B-2 or Form U-6B-2/A. Each record is materialized as one accession folder containing a metadata.json describing the submission and the original certificate body document plus any non-image exhibits preserved from the EDGAR submission.

Who was required to file Form U-6B-2?

Registered holding companies under PUHCA 1935 and their subsidiaries — operating electric and gas utilities, intermediate holding-company subsidiaries, Section 13 service companies, and certain non-utility subsidiaries within a registered system. Where the issuance, renewal, or guarantee occurred at the subsidiary level, the subsidiary was the filer and typically named its parent registered holding company in the certificate.

What time period does the dataset cover, and is it still being updated?

The dataset covers filings from January 1994, when EDGAR began accepting PUHCA filings, through early 2006. It is closed: the Energy Policy Act of 2005 repealed PUHCA 1935 effective February 8, 2006, which discontinued Form U-6B-2 and ended the filing program. No new records can arise after that date.

What file format is the dataset distributed in?

The dataset is delivered as monthly ZIP archives keyed by <year>/<year>-<month>.zip. Each archive decompresses to a directory containing one accession folder per filing, with file types TXT, JSON, HTML, and (occasionally) PDF for exhibits. Body documents are wrapped in EDGAR's SGML <DOCUMENT> envelope; pre-2002 filings are typically ASCII text and post-2002 filings are typically HTML.

How does this dataset differ from Form U-1 declarations?

Form U-1 was a pre-transaction declaration filed in advance to obtain SEC authorization, with prospectus-style economics, capitalization tables, and an order process. Form U-6B-2 is the post-transaction certificate filed only when the issuance proceeded under the self-executing Section 6(b) exemption and was therefore not the subject of any U-1. The two filings are mutually exclusive for any given transaction.

How can I reliably isolate PUHCA-regime filings within the metadata?

Two fields in metadata.json are diagnostic: entities[].act is "35" (Public Utility Holding Company Act of 1935) and entities[].fileNo is prefixed 040- (the PUHCA file-number range, e.g. "040-00545"). These two values do not appear in mainstream Securities Act or Exchange Act EDGAR datasets and are reliable filters for identifying PUHCA-regime filings.