Form C-U-W Files Dataset

The Form C-U-W Files Dataset packages every Form C-U-W submission filed on EDGAR — the structured filing an issuer uses to formally withdraw a previously transmitted Form C-U progress update under Regulation Crowdfunding (17 CFR Part 227, implementing Section 4(a)(6) of the Securities Act of 1933). One record corresponds to one EDGAR accession, keyed by an 18-digit accession number, and resolves to a self-contained per-accession folder containing the structured XML payload and a JSON metadata index. The legal filer is always the Reg CF issuer that previously submitted the C-U being unwound; intermediaries do not file C-U-W. Coverage runs from the earliest observed filing in December 2017 through the present, with content packaged as year-month ZIP containers (YYYY/YYYY-MM.zip) that hold XML and JSON files.

Dataset APIs

Dataset Files

What This Dataset Contains

The dataset captures Form C-U-W as an XML-only structured submission in EDGAR's http://www.sec.gov/edgar/formc namespace, accompanied by an SGML envelope that EDGAR uses to wrap the complete submission text. Form C-U-W is the withdrawal counterpart to Form C-U: where Form C-U reports an issuer's progress toward the target offering amount during a Regulation Crowdfunding offering, Form C-U-W exists solely so the issuer can rescind a previously transmitted C-U from the public record. The form's purpose is purely to withdraw — not to amend, restate, or supplement — so the substantive payload is intentionally minimal. Original economic content (target amount, progress, securities offered, intermediary, deadline) lives on the parent C / C-U chain being unwound, not on the C-U-W itself.

C-U-W has been part of the EDGAR Regulation Crowdfunding form family since the framework's effective date in 2016, and the underlying schema has been stable across the dataset's full history. There is no HTML rendering, ASCII narrative, PDF, or XBRL representation of the filing — the structured XML is the canonical form. In the dataset's packaging, each record materializes as a per-accession folder living inside a year-month ZIP container. The ZIPs are organized as YYYY/YYYY-MM.zip, and each ZIP unpacks to a YYYY-MM/ directory whose immediate children are folders named with the dashless 18-digit accession (for example 000166516025000347). Every such folder is one record and is fully self-contained — nothing about the record depends on sibling folders or on data outside the archive. Form C-U-W is rarely used, so monthly volume is low and uneven across the time series; many year-month containers hold a single record or none at all.

Content Structure of a Single Record

Files present per record

Each accession folder contains exactly two files:

The dataset omits image files; for C-U-W this exclusion is academic because the form does not carry image attachments, exhibits, or supporting documents. There is no XBRL instance, no R-files, no Financial_Report.xlsx, no separate exhibit XML, and no SGML <DOCUMENT> wrapper inside the folder. The SGML "complete submission text file" that EDGAR maintains on its own servers (referenced from metadata.json via linkToTxt) is not packaged into the per-accession folder; only the structured XML payload and the JSON index are included. A full record typically occupies under 5 KB on disk.

Anatomy of metadata.json

metadata.json is a flat JSON object that mirrors the EDGAR submission header and indexes the documents associated with the accession. The fields populated for a C-U-W record are:

• formType — always the string "C-U-W".
• accessionNo — the dashed accession number (for example 0001665160-25-000347).
• filedAt — ISO-8601 timestamp with timezone offset, capturing the EDGAR acceptance time.
• description — human-readable form name, typically "Form C-U-W - Progress Update Withdrawal".
• id — opaque internal hash identifier for the record.
• linkToFilingDetails — URL to primary_doc.xml on sec.gov.
• linkToTxt — URL to the SGML complete-submission .txt on EDGAR.
• linkToHtml — URL to the EDGAR -index.htm page for the accession.
• linkToXbrl — empty string, since C-U-W has no XBRL payload.
• documentFormatFiles — array enumerating the documents in the EDGAR submission. For a C-U-W there are typically two entries: one with sequence: "1" and type: "C-U-W" pointing to primary_doc.xml, and one with sequence: " ", type: " ", and description: "Complete submission text file" pointing to the SGML .txt. Each entry carries size (byte count, encoded as a string) and documentUrl.
• entities — an array of parties to the filing. For C-U-W the array has cardinality one — a single filer entity describing the issuer — with fields cik, companyName (suffixed (Filer)), type ("C-U-W"), fileNo (the EDGAR file number assigned to the Reg CF offering, e.g. 020-35353), irsNo, stateOfIncorporation, fiscalYearEnd (MMDD form), act ("33", identifying the Securities Act of 1933), and filmNo. Withdrawal of a progress update is an issuer-only action, so there are no co-filers, intermediaries, or related-party entries.
• seriesAndClassesContractsInformation — empty array; not used for C-U-W.
• dataFiles — empty array; C-U-W carries no data exhibits.

The fileNo value is the most useful join key in the JSON: it is the same Reg CF file number that appears on the parent Form C, on the Form C-U being withdrawn, and inside the XML's headerData. It is the natural lookup for stitching a withdrawal back to the offering and the underlying progress update.

Anatomy of primary_doc.xml

primary_doc.xml is an XML document whose root is <edgarSubmission> in the namespace http://www.sec.gov/edgar/formc. It has two top-level branches: <headerData> (the submission envelope) and <formData> (the substantive content). The full payload is on the order of 1–2 KB.

<headerData>

The header carries the EDGAR-level routing and credentialing information for the submission:

• <submissionType> — fixed at C-U-W.
• <filerInfo> containing:
  • <filer> with <filerCredentials> (a <filerCik> such as 0002025387 and a <filerCcc> access code that is always masked as XXXXXXXX in the public archive copy) and a <fileNumber> matching the EDGAR file number assigned to the Reg CF offering.
  • <liveTestFlag> — LIVE for production filings, TEST for test submissions.
  • <flags> — three boolean flags: <confirmingCopyFlag>, <returnCopyFlag>, and <overrideInternetFlag>, each holding true or false.

<formData>

The body of the form is intentionally sparse, which reflects the regulatory function of the filing — withdrawing a previously filed C-U does not require restating the offering. Two child elements are present:

• <issuerInformation> containing a single <issuerInfo> element with one populated field, <nameOfIssuer>, holding the issuer's legal name. There are no offering-amount, target-amount, deadline, security-type, intermediary, or progress fields anywhere in the C-U-W body. The form does not echo back the progress data being withdrawn.
• <signatureInfo> containing two structured groups:
  • <issuerSignature> — the issuer-level signature block, with <issuer> (the issuing entity name), <issuerSignature> (the signer's printed name), and <issuerTitle> (the signer's role at the issuer).
  • <signaturePersons> — a list of <signaturePerson> entries, each containing <personSignature> (printed name), <personTitle> (role), and <signatureDate> formatted as MM-DD-YYYY. One or more persons typically sign; multi-signer filings (for example an executive officer plus an additional principal-financial or board-level signer) are common.

Included content

The dataset includes, per accession:

• The full structured C-U-W XML payload exactly as it sits on EDGAR (the primary_doc.xml), preserving the formc namespace, header credentials (with masked CCC), filer flags, issuer name, and the complete signature block including signer names, titles, and dates.
• A JSON metadata index that captures the EDGAR submission header, the document inventory, the filer entity record (CIK, file number, IRS number, state of incorporation, fiscal year end, film number), and convenience URLs back to the original EDGAR artifacts.

Excluded or separate content

Excluded from the per-accession folder:

• Image files of any kind, by dataset policy.
• The SGML <SEC-DOCUMENT> / <DOCUMENT> complete-submission wrapper — that wrapper exists on EDGAR (and is reachable via the linkToTxt URL in metadata.json) but is not packaged inside the ZIP.
• The unmasked filer CCC, which is redacted to XXXXXXXX in the public copy.
• The parent Form C, Form C/A, and Form C-U filings being unwound: a C-U-W record does not embed or duplicate the offering details from the prior filings. Reconstructing the offering context requires joining on fileNo or cik against the corresponding C / C-U filings, which live in their own datasets.

Stability of structure

The record structure has been stable across the dataset's full history. C-U-W was introduced as part of EDGAR's Regulation Crowdfunding form family when Reg CF took effect, and the XML schema in the http://www.sec.gov/edgar/formc namespace has carried the same <headerData> / <formData> skeleton, the same <submissionType>C-U-W</submissionType> discriminator, the same minimal <issuerInformation> body, and the same <signatureInfo> block since the form's inception. There has been no migration through ASCII, HTML, or iXBRL representations. The JSON index layer is a packaging artifact applied uniformly across the dataset rather than a property of the underlying filing, so its field shape is consistent across years.

Interpretation notes

• A C-U-W does not, by itself, identify the specific Form C-U accession being withdrawn via an explicit accession reference. The linkage is implicit through the EDGAR fileNumber (which appears both in headerData/filerInfo/filer/fileNumber and in metadata.json.entities[].fileNo) and the issuer CIK. Consumers seeking the withdrawn C-U must search the same fileNo and cik across the C-U dataset, typically taking the most recent C-U preceding the C-U-W's filedAt timestamp.
• The dataset description's mention of "related offering details as reported on the original Form C-U submission" should be read as context, not as a promise that those fields are present in the C-U-W payload. Offering amounts, target amounts, deadlines, and progress figures are not part of the C-U-W XML and therefore are not part of the record. They reside on the parent filings.
• The filerCcc value is always XXXXXXXX. It is not data; it is a redaction, and any extractor should treat it as a constant rather than a variable.
• signaturePersons is a repeating structure. A C-U-W may legitimately carry multiple signers with different titles and a shared signatureDate, and downstream extraction should preserve the list rather than collapsing it to a single signer. Note also that the same individual may appear both as the <issuerSignature> block signer and as one of the <signaturePerson> entries, so a naive count of signatories should deduplicate.
• The signature date is rendered MM-DD-YYYY in the XML, which differs from the ISO-8601 filedAt timestamp in metadata.json. The two dates are not necessarily identical: signature dates reflect when the signatories executed the form, while filedAt reflects EDGAR acceptance.
• Because the form's body is so small, machine extraction is straightforward, but the value of a C-U-W record largely lies in the join: it is most useful as an event marker against the C / C-U chain rather than as a stand-alone disclosure of offering economics.

Who Files or Publishes This Dataset, and When

Who files the record

The legal filer of every Form C-U-W is the issuer that conducted the underlying Regulation Crowdfunding offering under Section 4(a)(6) of the Securities Act of 1933, implemented by 17 CFR Part 227. The filer is identified on the form by name and CIK. The filer population is narrow:

• privately held, non-reporting U.S. operating companies (typically corporations or LLCs)
• relying on the Section 4(a)(6) exemption to raise capital from retail investors
• excluded under 17 CFR 227.100(b): Exchange Act reporting companies, investment companies, foreign issuers, blank-check companies, and certain disqualified entities

Reg CF requires every offering to be conducted exclusively through a single registered intermediary, either a FINRA-registered funding portal under 17 CFR Part 227 Subpart C or a registered broker-dealer. The intermediary hosts the offering, collects investor commitments, and supplies the progress data that populates Form C-U. It is not a filer of the C-U-W and is not named on the form, though intermediaries or affiliated filing agents commonly prepare and transmit the EDGAR submission on the issuer's behalf using the issuer's credentials. The disclosure obligation rests solely with the issuer.

When the record is created or required

Form C-U-W is permissive, not mandatory. There is no Rule under Regulation CF that requires an issuer to file one, and no statutory deadline applies. It is filed only when an issuer needs to retract a previously submitted Form C-U progress update.

The underlying obligation that produces the C-U records being withdrawn is Rule 203(a)(3) of Regulation Crowdfunding (17 CFR 227.203(a)(3)), which requires the issuer to file Form C-U:

• within five business days after reaching 50 percent of the target offering amount
• within five business days after reaching 100 percent of the target offering amount
• within five business days after the offering deadline, reporting total securities sold

(The 50 percent and 100 percent progress updates are not required where the intermediary makes equivalent commitment information continuously and publicly available on its platform; the final post-deadline C-U is still required.)

Typical situations that trigger a C-U-W:

• Erroneous or duplicate filings. A C-U filed against the wrong CIK, attached to the wrong offering, containing incorrect progress figures, or duplicating an existing C-U.
• Correction by withdraw-and-refile. Regulation CF provides no "C-U/A" amendment form, so an issuer correcting an inaccurate progress update withdraws the prior C-U via C-U-W and submits a fresh C-U.
• Premature or out-of-sequence filing. A C-U submitted before the relevant 50 or 100 percent threshold was actually reached.
• Progress update rendered moot. A prior C-U that has become misleading because of early termination, abandonment, or restructuring of the offering through Form C/A.

A C-U-W does not relieve the issuer of any Rule 203(a)(3) obligation. If the underlying milestone has in fact been reached, an accurate replacement C-U remains required.

Important distinctions

• C-U-W withdraws only the targeted progress update. It removes the single Form C-U identified by accession number on its face. It does not amend, terminate, or withdraw the underlying offering, the original Form C offering statement, or any other C-U, C-AR, or C-TR on file.
• C-U-W versus C-W. Form C-W withdraws the offering statement on Form C and retracts the offering itself. Form C-U-W leaves the offering and Form C intact.
• C-U-W versus C-AR-W. Form C-AR-W withdraws an annual report on Form C-AR filed under Rule 202. C-U-W operates on offering-period progress reports under Rule 203, not annual reports.
• Filer versus preparer. The issuer is always the legal filer. Funding portals, broker-dealers, and third-party filing agents may prepare and transmit the filing but are not parties to the disclosure obligation and do not appear as filers.
• Outside the population. Issuers using Regulation D Rule 506, Regulation A under Section 3(b)(2), or registered offerings do not file in the Form C family at all. Every C-U-W in the dataset corresponds to an issuer that previously made a Section 4(a)(6) offering and previously filed at least one Form C-U.
• No amendment of a withdrawal. There is no "C-U-W/A." A C-U-W is itself the terminal administrative act for the targeted C-U; corrections to a mistaken withdrawal are handled operationally with EDGAR.
• Earliest possible date. Regulation Crowdfunding took effect May 16, 2016, so no Form C-U-W can predate that. The dataset's earliest observed filing in December 2017 reflects the first actual C-U-W submission, not an EDGAR availability cutoff.

How This Dataset Differs From Similar Datasets or Filings

Form C-U-W belongs to the Regulation Crowdfunding family, which is unusual in giving each periodic filing its own dedicated withdrawal counterpart rather than relying on amendments. C-U-W is narrowly the withdrawal of a single progress update (Form C-U), so the most useful comparisons are with the other Reg CF forms and with how withdrawal works in adjacent exempt-offering regimes (Reg A, Reg D).

Form C-U (progress update)

C-U is the filing C-U-W exists to retract. Under Rule 203(a), an issuer files C-U to report progress toward the target offering amount at defined thresholds (50%, 100%, and final amount raised at close). C-U carries dollar figures, the measurement date, and offering identifiers.

C-U-W is procedural: its payload is a pointer to the specific C-U being withdrawn plus a short reason. It reports no new progress data and does not amend the withdrawn C-U — Reg CF has no "C-U/A" amendment form, so C-U-W is the only correction path for a flawed progress update. For a panel of fundraising progress, pull C-U for content and use C-U-W as a retraction flag.

Form C-W (offering statement withdrawal)

C-W is the most easily confused neighbor and the most important to keep separate. Both are Reg CF withdrawals, but C-W operates at the offering-statement level: it withdraws Form C and pulls the entire offering. After a C-W, no further C-U progress updates are expected.

C-U-W operates at the progress-update level only. It does not unwind the Form C, does not invalidate the offering, and does not block subsequent C-U filings. Researcher consequence: a C-W signals an offering that never completed under Reg CF; a C-U-W signals only that one progress observation should be disregarded. Treating the two as a combined "Reg CF withdrawals" series would conflate offering exits with data corrections.

Form C-AR-W (annual report withdrawal)

C-AR-W is the structural twin of C-U-W applied to the annual report (Form C-AR) rather than the progress update. Both are short, procedural withdrawals of a specific prior filing in the Reg CF post-offering chain.

The retracted content differs sharply: C-AR-W removes a full year of substantive disclosure (financials, business updates), while C-U-W removes a brief threshold update. C-AR-W filings are accordingly more consequential for ongoing-reporting integrity. The two datasets do not substitute for each other — pair C-AR with C-AR-W for annual-reporting analysis, and C-U with C-U-W for offering-period progress.

Form C and Form C/A (offering statement and amendments)

C and C/A define the offering that a later C-U reports against. They are orders of magnitude richer than C-U-W in disclosure content (business description, financials, target, deadline, risk factors). C-U-W never restates offering terms — it only withdraws a status update tied to an offering already established by C/C-A. Use C and C/A for what was offered; use C-U/C-U-W for how the offering progressed and what was retracted.

Form C-TR (termination of reporting)

Form C-TR ends an issuer's ongoing Reg CF reporting obligations on a forward-looking basis (e.g., when Rule 202(b) conditions are met). It is not a withdrawal of any specific prior filing.

Versus C-U-W: C-TR closes a reporting stream; C-U-W retracts one observation inside an active stream. C-TR tells you when an issuer leaves the Reg CF reporting universe; C-U-W tells you which past progress points were pulled from the record.

Withdrawal mechanics in adjacent regimes

Reg A — Form 1-A-W and 1-A/A. Reg A's offering-statement withdrawal is Form 1-A-W, the analog of C-W (not C-U-W). Reg A's ongoing reports (1-K, 1-SA, 1-U) have no per-filing withdrawal forms — corrections go through amendments. The closest functional cousin of C-U-W on the Reg A side is therefore 1-A/A or report-specific amendments, but the dataset shape and semantics are different: amendments leave the original on the record, while C-U-W formally retracts it.

Reg D — Form D and Form D/A. Reg D has no withdrawal mechanism at all. Issuers correct prior notices through Form D/A; there is no SEC concept of "unfiling" a Form D. This is the sharpest contrast with Reg CF, which treats progress updates and annual reports as discrete, individually retractable filings. A researcher mapping correction patterns across exempt offerings should not look for a Reg D equivalent of C-U-W.

Boundary summary

Form C-U-W is distinguished by a precise combination: (1) a withdrawal rather than a substantive disclosure or amendment, (2) scoped to a single progress update rather than to the offering statement (C-W), the annual report (C-AR-W), or the reporting stream as a whole (C-TR), and (3) confined to Reg CF, where per-filing withdrawal forms are an architectural choice not mirrored in Form 1-A Reg A or Form D Reg D. C-U is its content-bearing partner; C-W and C-AR-W are its structural siblings at different scopes; C-TR closes the stream rather than retracting within it; Reg A and Reg D analogs are only loose because those regimes correct via amendment. The dataset is small and inherently complementary — most useful when joined to C-U to mark which progress observations were withdrawn from EDGAR, and rarely informative on its own.

Who Uses This Dataset

Form C-U-W is a low-volume Regulation Crowdfunding filing, but a defined set of practitioners depend on it. Across user groups, the same fields drive the work: issuer CIK, the accession number of the withdrawn Form C-U (resolved through fileNo), the filing/withdrawal timestamps, and the signatory block.

Reg CF securities counsel

Counsel advising Reg CF issuers and conducting issuer-side diligence pull the C-U-W to confirm a flawed progress update has been formally rescinded before issuing opinion letters or clearing a follow-on Form C/A. They tie the C-U-W accession number to the original C-U accession, check the gap between filing and withdrawal, and verify the signatory matches the issuer's authorized officer. Output: corrective filing memos, Section 4(a)(6) exposure analyses, and clean disclosure timelines for a target issuer.

Funding portal compliance officers

Compliance staff at registered funding portals reconcile each C-U-W against their internal offering ledger. They match issuer CIK and the withdrawn accession number to the offering record, confirm the signatory against onboarding KYC, and log the event in the supervisory file required under Rule 403. Output: escalation memos, AML review entries, and annual compliance documentation.

SEC and FINRA examination staff

Examiners screen C-U-W filings to flag issuers with patterns of withdrawn progress data, short filing-to-withdrawal intervals, or repeat signatory turnover. They use the link between the C-U-W and original C-U accession to reconstruct what was rescinded and when. Output: exam targeting lists, complaint triage notes, and enforcement referrals on Reg CF reporting integrity.

Crowdfunding platform operations teams

Product and ops teams at intermediaries use issuer CIK, withdrawal timestamp, and original accession to update issuer profile pages, invalidate stale progress figures on investor-facing dashboards, and trigger internal alerts. Output: accurate filing trackers, ledger hygiene, and corrected post-offering reports to the issuer.

Forensic and fraud researchers

Forensic accountants and integrity researchers treat C-U-W events as one signal in a broader red-flag screen. They focus on repeat withdrawals tied to the same CIK, the latency between original C-U and withdrawal, and signatory consistency across an issuer's filings. Output: diligence checklists for prospective Reg CF investors and fraud-typology evidence.

Reg CF auditors and accountants

CPAs preparing or reviewing financials for Form C and Form C-AR check whether the client has withdrawn prior progress updates. They reconcile the withdrawn accession numbers and dates with management representations and internal records. Output: completeness testing on EDGAR submissions, subsequent-events review, and audit working papers.

Academic researchers on Title III crowdfunding

Researchers in finance, law, and entrepreneurship merge C-U-W records with Form C, C/A, C-U, C-AR, and C-TR filings on issuer CIK to build longitudinal panels of Reg CF disclosure behavior. Filing and withdrawal timestamps support latency studies. Output: empirical work on Reg CF disclosure quality and policy analysis of Title III effectiveness.

Filing-history data vendors

Data engineering teams at EDGAR aggregators ingest the metadata file, accession number, CIK, and form type to wire withdrawal events into parent issuer records and annotate the superseded C-U on downstream dashboards. Output: coherent Reg CF filing timelines on commercial terminals and clean event feeds to subscribers.

Trade-press journalists covering private markets

Reporters at crowdfunding-focused trade publications use issuer name, CIK, withdrawal date, and the link to the original C-U to surface stories on retracted progress claims, recurring patterns at specific issuers, or sector-level disclosure quality. Output: investigative pieces and data-driven explainers.

RAG and LLM engineers building Reg CF assistants

Engineers indexing Reg CF filings use form-type tags and accession-number linkages so retrieval systems do not surface withdrawn progress data as current. Output: diligence copilots, internal search at intermediaries, and compliance assistants that correctly reflect rescissions.

Synthesis

The user base concentrates on Reg CF compliance, supervision, and research. Counsel and portal compliance teams reconstruct disclosure timelines; regulators and forensic researchers use the filing as an integrity signal; academics, vendors, auditors, journalists, and retrieval-system builders maintain accurate views of the Reg CF universe. The same four fields — CIK, withdrawn accession number, timestamps, and signatory — drive every workflow.

Specific Use Cases

Form C-U-W is rarely useful on its own and almost always works as an event flag joined back to the parent C and C-U filings on fileNo and cik. The use cases below reflect that join-and-flag pattern.

1. Reconciling withdrawn progress updates against a Reg CF offering ledger

A funding portal compliance officer pulls every C-U-W where the issuer's cik and entities[].fileNo match an offering hosted on the portal. The officer matches each accessionNo and filedAt against the portal's internal C-U log, identifies the original C-U being retracted (most recent C-U on the same fileNo preceding filedAt), and verifies the signers in signaturePersons against onboarding KYC records. Output: a Rule 403 supervisory entry per withdrawal and an AML escalation memo when the signer or signing date looks anomalous.

2. Cleaning superseded progress data in an EDGAR aggregator's filing timeline

A data vendor ingests metadata.json for each C-U-W, reads formType, accessionNo, the filer cik, and fileNo, and uses those values to flag the most recent prior Form C-U on the same fileNo as withdrawn on the issuer's filing-history page. The XML is not needed for this step; the JSON header is sufficient. Output: a "Withdrawn" badge on the superseded C-U in commercial terminals and a structured event in the customer-facing change feed.

3. Confirming rescission before a follow-on Reg CF filing

Reg CF issuer counsel preparing a Form C/A or a corrected Form C-U opens the C-U-W primary_doc.xml to confirm the issuer name in <nameOfIssuer>, the <fileNumber> in <headerData>, and the executed <signatureInfo> block (signer name, title, signatureDate in MM-DD-YYYY). Counsel cross-checks the filedAt timestamp against the date of the flawed C-U to document the gap. Output: a clean disclosure timeline exhibit attached to the corrective filing memo and Section 4(a)(6) exposure note.

4. Building a longitudinal Reg CF disclosure-behavior panel

An academic researcher merges all C-U-W records with the C, C/A, C-U, C-AR, and C-TR datasets on cik and fileNo to construct an issuer-level event panel. From each C-U-W the researcher takes filedAt, the inferred withdrawn-C-U accession, and the signer roster, and computes filing-to-withdrawal latency and repeat-withdrawal counts per issuer. Output: descriptive statistics on Reg CF correction behavior and regression covariates for studies of Title III disclosure quality.

5. Targeting examinations on Reg CF reporting integrity

SEC or FINRA examination staff scan the full set of C-U-W filings for clusters: multiple withdrawals tied to the same cik, short intervals between the C-U filedAt and the C-U-W filedAt, or signatory turnover across the signaturePersons block between an issuer's filings. Because the universe is small, this is a manual review rather than a statistical screen. Output: an exam targeting list and complaint-triage notes flagging issuers and intermediaries for closer review.

6. Indexing rules for a Reg CF retrieval or RAG system

An engineer building a diligence copilot over Reg CF filings uses formType: "C-U-W" and the filer cik/fileNo to mark the most recent prior C-U on the same offering as superseded in the vector index, so the assistant does not surface retracted progress numbers as current. The C-U-W payload itself contributes the issuer name and signer block but no offering economics. Output: a retrieval policy that downranks or excludes withdrawn C-U content and an audit log of which progress updates were suppressed.

7. Investigating retracted progress claims for trade-press coverage

A journalist covering crowdfunding takes the issuer name from <nameOfIssuer>, the linkToHtml URL, and the filedAt date from metadata.json, then follows fileNo back to the offering page to compare the withdrawn C-U's reported progress with later disclosures or platform marketing. Output: a story documenting a retracted milestone claim with direct EDGAR citations to both the original C-U and the C-U-W.

Dataset Access

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

This endpoint returns dataset-level metadata (name, description, updatedAt, earliestSampleDate, totalRecords, totalSize, formTypes, containerFormat, fileTypes), the full dataset download URL, and the containers[] array listing every monthly ZIP with its key, size, records, updatedAt, and downloadUrl. Use it to enumerate available containers and to monitor which monthly archives changed in the most recent refresh, so downstream pipelines can pull only the updated months. No API key is required to call the index endpoint.

          1
          {
        

          2
            "datasetId": "1f13365b-9ae0-6a58-a9ac-a0e18729e2ce",
        

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

          4
            "name": "Form C-U-W Files Dataset",
        

          5
            "updatedAt": "2026-04-16T08:46:44.621Z",
        

          6
            "earliestSampleDate": "2017-12-01",
        

          7
            "totalRecords": 23,
        

          8
            "totalSize": 32900,
        

          9
            "formTypes": ["C-U-W"],
        

          10
            "containerFormat": "ZIP",
        

          11
            "fileTypes": ["XML", "JSON"],
        

          12
            "containers": [
        

          13
              {
        

          14
                "downloadUrl": "https://api.sec-api.io/datasets/form-cuw-files/2025/2025-03.zip",
        

          15
                "key": "2025/2025-03.zip",
        

          16
                "size": 4821,
        

          17
                "records": 2,
        

          18
                "updatedAt": "2026-04-16T08:46:44.621Z"
        

          19
              }
        

          20
            ]
        

          21
          }
        

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

Returns a single ZIP archive containing every Form C-U-W filing from December 2017 to the present, organized by year and month. This endpoint requires a valid SEC API key passed via the token query parameter.

Download Single Container: https://api.sec-api.io/datasets/form-cuw-files/2025/2025-03.zip?token=YOUR_API_KEY

Each container is a year-month ZIP (e.g., form-cuw-files/2025/2025-03.zip) covering all C-U-W filings submitted in that month. Build container URLs by appending the key from the index containers[] array to the dataset base path, or use the downloadUrl field returned directly by the index. This endpoint requires a valid SEC API key passed via the token query parameter.

Frequently Asked Questions

What form does this dataset cover?

The dataset covers Form C-U-W, the structured filing an issuer uses to formally withdraw a previously filed Form C-U progress update under Regulation Crowdfunding (17 CFR Part 227). It is the withdrawal counterpart to Form C-U and is filed only when an issuer needs to retract a previously transmitted progress update from the public EDGAR record.

What does one record in this dataset represent?

One record represents a single Form C-U-W submission filed on EDGAR, keyed by an 18-digit accession number. Each record is a self-contained per-accession folder containing exactly two files: primary_doc.xml (the structured C-U-W payload in the http://www.sec.gov/edgar/formc namespace) and metadata.json (the EDGAR submission header and document index).

Who is required to file Form C-U-W?

No issuer is required to file Form C-U-W — the form is permissive, not mandatory. It is filed by the Reg CF issuer that conducted the underlying Section 4(a)(6) offering and that previously submitted at least one Form C-U progress update, only when the issuer needs to retract such a progress update. Funding portals and broker-dealers may prepare and transmit the filing but are never the legal filer.

What time period does the dataset cover?

The dataset's earliest sample date is December 1, 2017, and coverage runs through the most recent monthly refresh. Although Regulation Crowdfunding took effect May 16, 2016, no Form C-U-W was actually submitted until December 2017, so the start date reflects first observed use rather than an EDGAR availability cutoff.

What file formats are included?

Each record includes one XML file (primary_doc.xml, the structured C-U-W payload) and one JSON file (metadata.json, the EDGAR submission header and document index). The dataset is distributed as year-month ZIP containers under the path pattern YYYY/YYYY-MM.zip. There is no XBRL, HTML, PDF, or image content because Form C-U-W is an XML-only structured form with no exhibits.

How does this dataset differ from Form C-W?

Form C-W withdraws the Form C offering statement and retracts the entire Reg CF offering, after which no further C-U progress updates are expected. Form C-U-W withdraws only a single progress update and leaves the underlying offering, the original Form C, and any other C-U, C-AR, or C-TR on file fully intact. Treating the two as a combined "Reg CF withdrawals" series would conflate offering exits with data corrections.

How do I link a C-U-W back to the specific Form C-U it withdraws?

Form C-U-W does not carry an explicit accession reference to the C-U being withdrawn. The linkage is implicit: use the EDGAR fileNumber (which appears in headerData/filerInfo/filer/fileNumber in the XML and as entities[].fileNo in metadata.json) together with the issuer CIK, then look up the most recent Form C-U on the same fileNo and cik whose filedAt precedes the C-U-W's filedAt.