SEC Form SBSEF-W Files Dataset

The SEC Form SBSEF-W Files Dataset is a structured collection of every Form SBSEF-W filing submitted to EDGAR — notices of withdrawal from registration as a security-based swap execution facility (SBSEF), filed under Section 3D of the Securities Exchange Act of 1934 and Regulation SE. Each record represents one EDGAR submission, identified by a unique accession number, and bundles the normalized filing metadata, the structured XML body of the submission, and EDGAR's XSL-rendered HTML view of that body. The filer is always an SBSEF that is currently registered with the SEC or has a pending registration application on file, signed by an authorized officer of the platform entity. Coverage begins in October 2024, when Regulation SE and the SBSEF registration regime became operational, and extends to the present. The dataset is distributed as monthly ZIP containers organized by year, with inner files in XML and JSON.

Dataset APIs

Dataset Files

What This Dataset Contains

The dataset captures every Form SBSEF-W filing accepted by EDGAR — the withdrawal counterpart to Form SBSEF, the registration application for a security-based swap execution facility. Form SBSEF-W is filed under Section 3D of the Securities Exchange Act of 1934 and Regulation SE, the Commission's rule set governing SBSEFs (adopted in 2023). Its purpose is to provide the Commission the information needed to determine whether withdrawal from SBSEF registration is consistent with the public interest and the protection of investors before the facility ceases operating in its registered capacity.

The filing itself is administrative, short, and event-oriented. Substantively, it carries identifying information for the withdrawing facility, the linkage to the original SBSEF registration file number, the LIVE-or-TEST submission flag, and the filer's signed credentials. Unlike a 10-K or proxy statement, there is no narrative discussion, no financial statements, and no exhibit list of substantive supporting documents — the informational value lies in the identity of the registrant, the timing of the filing, and the file-number linkage back to the original registration.

The dataset covers the entire Form SBSEF-W filer population from the earliest possible filings (October 2024) forward. Records are distributed inside monthly ZIP containers; inner files are XML (the submission body and its XSL-rendered HTML view) and JSON (the normalized filing metadata).

Content Structure of a Single Record

What one record represents

A single record in the Form SBSEF-W Files Dataset corresponds to one EDGAR submission of Form SBSEF-W, identified by a unique EDGAR accession number. Each record materializes on disk as one accession-numbered subfolder inside a monthly ZIP archive and bundles three artifacts: the normalized filing metadata, the structured XML body of the submission, and EDGAR's XSL-rendered HTML view of that same body.

The record unit is one accession, not one filer and not one calendar period. A facility that withdraws, later re-registers, and then withdraws again would appear as two distinct records, each tied to its own accession number. There is no aggregation across filers or rolling-up across time at the record level.

On-disk layout of one record

Records are distributed inside monthly ZIP containers organized by year. Each ZIP unpacks to a top-level folder named after the calendar month (for example, 2024-10/). Beneath that month folder, every Form SBSEF-W filing occupies its own subfolder named after the EDGAR accession number in compact dashless form (for example, 000087265124000012/). Inside an accession folder, a record consists of exactly three files:

• metadata.json — a normalized JSON object describing the filing, the filer entity or entities, and every document attached to the EDGAR submission.
• primary_doc.xml — the raw EDGAR submission XML for Form SBSEF-W, carrying the structured form body in the http://www.sec.gov/edgar/sbsefwvfiler namespace.
• xslSBSEF-W_X01/primary_doc.xml — the HTML rendering of the same submission produced by EDGAR's XSL transform. Despite the .xml extension, the file content is XHTML 1.0 Strict and is intended for human display.

Image attachments from the original EDGAR submission are excluded from the dataset bundle. Every other component of the original submission package is either preserved as a file in the accession folder or referenced by absolute URL inside metadata.json.

The metadata.json object

metadata.json is a flat JSON object summarizing one accession. Its fields divide into four functional groups.

Filing identity and routing. These fields locate the filing within EDGAR:

• formType — fixed at SBSEF-W for every record in this dataset.
• accessionNo — the canonical EDGAR accession number written with dashes (for example, 0000872651-24-000012).
• id — a dataset-internal record identifier.
• filedAt — the ISO 8601 timestamp of EDGAR acceptance, including offset.
• description — the human-readable form description, typically Form SBSEF-W - Request for Withdrawal of Application for Registration.
• linkToFilingDetails, linkToTxt, linkToHtml, linkToXbrl — absolute URLs to the rendered filing page on sec.gov, the complete submission .txt file, the EDGAR filing index, and the XBRL data location respectively. linkToXbrl is empty because the form does not carry XBRL data.

Document inventory.

• documentFormatFiles — an array of document objects, each carrying sequence, size, documentUrl, type, and optionally description. The array mirrors the EDGAR submission's document table and enumerates every component of the original submission, including the structured XML body, the XSL-rendered HTML, and the complete submission text file.

Filer entity information.

• entities — an array of filer-entity objects representing the parties on the EDGAR cover page. Each entry typically carries cik, companyName (suffixed with the role indicator, such as (Filer)), fileNo (the SBSEF registration file number being withdrawn, in the 039- series), irsNo, stateOfIncorporation, fiscalYearEnd, act, filmNo, and type. Together these fields identify the withdrawing facility and tie the withdrawal back to the original SBSEF registration record.

Schema holdovers. Two arrays are part of the broader EDGAR metadata schema but carry no payload for this form type:

• seriesAndClassesContractsInformation — empty for SBSEF-W filings, which do not concern fund series or classes.
• dataFiles — empty for SBSEF-W filings, which do not produce structured data exhibits.

The primary_doc.xml submission body

The structured body of the filing is a small XML document in the http://www.sec.gov/edgar/sbsefwvfiler namespace. The root element is edgarSubmission and contains exactly two children: headerData and formData.

headerData carries the submission identity and the filer credentials:

• submissionType — the literal value SBSEF-W.
• filerInfo — wraps one or more filer blocks together with a liveTestFlag.
  • filer.filerCredentials.cik — the 10-digit CIK of the withdrawing SBSEF.
  • filer.filerCredentials.ccc — the EDGAR filer access code, redacted in the dataset to XXXXXXXX.
• liveTestFlag — LIVE for production filings or TEST for test submissions, distinguishing real withdrawals from EDGAR test traffic.

formData is the placeholder for the substantive form body. For Form SBSEF-W, this element is intentionally minimal and may be empty in practice: the form's substantive content (identification of the facility, the effective date of withdrawal, representations about the wind-down of operations, and any required certifications) is conveyed primarily through the EDGAR header metadata captured in metadata.json and through the rendered HTML cover page rather than through deeply nested form-data elements. Consumers should not expect a rich element tree under formData for this form type.

The XSL-rendered HTML

The file at xslSBSEF-W_X01/primary_doc.xml is EDGAR's XSL-driven HTML rendering of the same submission. It declares an XHTML 1.0 Strict doctype, embeds the EDGAR cover-page CSS, and presents a formatted table titled SBSEF-W: Filer Information. The rendering surfaces the same fields drawn from headerData — CIK, CCC (redacted), and the LIVE/TEST flag — in a layout intended for human review. It also exposes the form's OMB control number (3235-0793) and the estimated burden hours, both of which are part of the official OMB-cleared form template rather than filer-supplied data.

Because the rendered HTML and the structured XML are two views of the same underlying submission, downstream extraction can take whichever surface is more convenient: the XML for parsable element access, or the HTML for human-facing presentation.

Included content

For each accession, the record includes the normalized metadata.json, the structured primary_doc.xml submission body, and the XSL-rendered HTML view of that body. The documentFormatFiles array additionally records URLs for every component of the original EDGAR submission, including the complete submission text file, allowing retrieval of any item not packaged locally.

Excluded or separate content

• Image files from the original EDGAR submission are not packaged in the dataset bundle.
• The CCC filer access code is redacted to XXXXXXXX in the structured XML, as is standard for any public release of EDGAR submission XML.
• Anything filed separately under a different accession number — for example, a related Form SBSEF amendment, a re-registration, or a later withdrawal — is a different record and not part of the same SBSEF-W bundle.

Interpretation and extraction notes

Several characteristics shape how records should be read and extracted:

• Authoritative identifier surfaces are in metadata.json. The identifying and event-defining facts of a withdrawal — filer name, CIK, SBSEF file number, state of incorporation, IRS number, and the EDGAR acceptance timestamp — are most reliably read from metadata.json rather than from the formData element of the submission XML, which is sparse for this form type.
• Accession number is the primary key. It appears in canonical dashed form inside metadata.json (accessionNo) and in dashless form as the on-disk folder name. The two forms are equivalent up to the dash placement.
• fileNo links back to the original registration. The fileNo field on the filer entity is the SBSEF registration file number (in the 039- series) being withdrawn; it is the join key from a withdrawal record to the original Form SBSEF registration filing.
• Empty-by-design fields. linkToXbrl, seriesAndClassesContractsInformation, and dataFiles are structurally present but empty for SBSEF-W. Treat their absence as expected, not as missing data.
• LIVE/TEST gating. Aggregations should filter on liveTestFlag == LIVE; only LIVE filings represent real withdrawals.
• Single-format era. Form SBSEF-W has only existed in a single EDGAR-structured era. Regulation SE was adopted in 2023, and the form was made available on EDGAR shortly thereafter. There is no ASCII or pre-HTML era for this form, no XBRL adoption history to track, and no historical evolution in required sections to reconcile; every record in the dataset shares the same modern XML-plus-XSL-HTML format.
• XML and HTML are redundant views. The XSL-rendered HTML is generated from the XML; it is not an independent source. Extraction pipelines can prefer the XML for structured access without losing information.

Who Files or Publishes This Dataset, and When

Who files the record

The filer is always a security-based swap execution facility ("SBSEF") that is either currently registered with the SEC under Section 3D of the Securities Exchange Act of 1934 or has a pending registration application on file. The legal filer is the SBSEF entity itself, signed by an authorized officer.

Key characteristics of the filer population:

• An SBSEF is a trading platform that brings multiple buyers and multiple sellers together to execute security-based swaps, predominantly single-name credit default swaps and equity-based swaps within SEC jurisdiction.
• Filers are infrastructure-level market participants, not issuers, insiders, fund managers, or institutional investment managers.
• The filer is the platform entity, not the parent holding company, the affiliated clearing agency, or the dealers and major participants that trade on the platform, even though those parties may be referenced in the notice.
• An applicant whose registration has not yet been granted may also file Form SBSEF-W to withdraw the pending application.

The population is very small. Only entities ever registered or applying as SBSEFs can appear, so the dataset is structurally sparse.

When the record is created or required

Form SBSEF-W is event-driven. It is filed only when a registered SBSEF (or applicant) elects to discontinue its registered status. There is no periodic schedule and no fixed post-event deadline of the kind that governs Form 4, Form 8-K, or Form 13F.

Typical triggering circumstances:

• winding down trading operations entirely;
• consolidating into an affiliated platform;
• migrating to a different regulatory regime, such as a CFTC-registered SEF, when the product mix no longer requires SBSEF status;
• abandoning a pending registration application; or
• exiting the security-based swap execution business as part of a corporate restructuring, sale, or dissolution.

Timing logic is forward-looking rather than deadline-driven:

• The filer specifies a proposed effective date of withdrawal in the form.
• The notice must be filed far enough ahead for the Commission to assess the withdrawal under the public interest and investor protection standard set by Section 3D.
• The Commission may accept the proposed date, postpone or accelerate it, or impose terms and conditions addressing open positions, customer obligations, recordkeeping, and surveillance data.
• Until the Commission's determination becomes effective, the filer remains a registered SBSEF subject to the full Regulation SE compliance framework.

The earliest possible Form SBSEF-W filings date from late 2024, when Regulation SE and the SBSEF registration regime became operational. No paper or pre-EDGAR analogue exists, because the registration category itself did not exist before then.

Important distinctions

• Filer versus affected parties. Only the SBSEF files. Security-based swap dealers, major security-based swap participants, eligible contract participants, and clearing agencies that use the platform are not filers, even though the withdrawal affects their venue access.
• SBSEF-W versus Form SBSEF. Form SBSEF is the registration application; Form SBSEF-W is the withdrawal counterpart. Amendments to a pending application are made through the Form SBSEF amendment process, not Form SBSEF-W.
• SBSEF-W versus CFTC SEF withdrawal. Platforms dually registered as a CFTC SEF and an SEC SBSEF must withdraw from each regime separately. Form SBSEF-W effects only the SEC SBSEF withdrawal.
• Voluntary versus involuntary exit. Form SBSEF-W covers only voluntary withdrawal initiated by the registrant. Commission-initiated revocation, suspension, or cancellation occurs through separate administrative proceedings and does not generate a Form SBSEF-W filing.
• Notice versus completed exit. The filing is a notice of intent. Withdrawal is not self-effectuating; actual exit from the SBSEF population occurs when the Commission's determination becomes effective.
• Other platform-withdrawal forms. National securities exchanges withdraw on Form 1-W; alternative trading systems use Form ATS-N amendments; broker-dealers use Form BDW; CFTC-only swap execution facilities use CFTC processes. Form SBSEF-W is reserved exclusively for exiting the SEC SBSEF regime under Title VII of the Dodd-Frank Act.

How This Dataset Differs From Similar Datasets or Filings

The most informative comparisons fall into three groups: other filings in the SBSEF lifecycle, SEC withdrawal forms for other registrant types, and venue-exit filings in adjacent regimes (CFTC SEFs, ATSs).

Form SBSEF (initial registration)

The entry-point counterpart to SBSEF-W. SBSEF is exhibit-heavy, documenting ownership, governance, rulebook, financial resources, system architecture, surveillance, and conflicts controls. SBSEF-W is a short closing notice ending that registration. They are complementary endpoints of the same record, not substitutes.

Form SBSEF amendments

Amendments modify a live registration (rules, governance, systems, ownership) while the venue keeps operating. SBSEF-W terminates the registration. A complete venue history chains SBSEF, its amendments, and finally SBSEF-W; only the last belongs in this dataset.

Form 1-W (national securities exchange withdrawal)

The closest structural analogue: a venue-level Section 6 exit requiring Commission consideration of investor protection and wind-down. Differs in market scope (equities/options exchanges) and in the obligations being unwound (member relationships, listed-issuer transitions, market-data feeds), versus SBSEF-W's open-trade handling, clearing connections, and SBS counterparty notifications.

Form BDW (broker-dealer withdrawal)

The closest analogue at the intermediary level. Both are short structured withdrawal forms with wind-down representations subject to Commission review. BDW concerns customer accounts, custody of securities and funds, books and records, and SIPC/SRO relationships. SBSEF-W concerns trading-platform wind-down. BDW has a much richer disclosure schedule reflecting a mature regime; SBSEF-W is structurally simpler because the regime is new and the registrant population is in the single digits.

Form ADV-W (investment adviser withdrawal)

Parallel withdrawal form for advisers, covering advisory client relationships, custody, and contract transition rather than venue operations. ADV-W datasets contain thousands of records; SBSEF-W will remain very small.

CFTC SEF withdrawal

CFTC SEFs execute non-security-based swaps (broad-based index, rates, FX, commodity). A SEF withdrawal is filed with the CFTC, not on EDGAR. Operationally the wind-down looks similar, but jurisdiction and product perimeter differ. A dually registered venue must file both; neither substitutes for the other.

ATS cessation (Form ATS-N amendment)

ATSs notify cessation through an amendment to ATS-N rather than a standalone withdrawal form. ATSs operate under Regulation ATS exemptive conditions, not full venue registration, and the disclosure focuses on subscriber notification and equities order handling. Different filing mechanics, different regulatory posture, different product scope.

Key differences

• Lifecycle position: SBSEF-W is exit-only; SBSEF and its amendments cover entry and ongoing changes.
• Registrant type: venue-level (vs. intermediary-level for BDW and ADV-W).
• Market scope: security-based swaps only (vs. equities/options for Form 1-W and ATSs; non-SBS swaps for CFTC SEFs).
• Filing channel: EDGAR under Regulation SE (vs. CFTC channels for SEF withdrawals).
• Filing structure: dedicated withdrawal form (vs. ATS cessation, which is an ATS-N amendment).
• Population and volume: tiny registrant base, infrequent filings (vs. high-volume ADV-W and BDW datasets).

Boundary summary

No other SEC dataset captures the deregistration of a security-based swap execution facility. Form 1-W covers the wrong market, BDW and ADV-W cover the wrong registrant type, ATS cessation uses the wrong filing structure, and CFTC SEF withdrawals fall outside SEC jurisdiction. SBSEF-W is the only source for the notice, effective date, and wind-down representations that end an SBSEF's registration; for a full venue history it must be paired with the original SBSEF filing and any amendments.

Who Uses This Dataset

Form SBSEF-W is a low-volume, narrow-purpose filing, and its users are correspondingly concentrated, professional, and focused on the operating status of regulated swap-trading venues. The fields that matter most across user types are the metadata.json header (CIK, accession number, file number, filing date) and the primary_doc.xml body (legal name, effective date of withdrawal, signatory, and wind-down representations).

Derivatives regulatory counsel

In-house counsel at SBSEFs and outside derivatives lawyers use prior filings as drafting precedents — structuring withdrawal narratives, wording representations on cessation of trading, transfer of open interest, and recordkeeping continuity, and calibrating the gap between filing date and effective date. Output: drafted SBSEF-W packages, deregistration sequencing memos, and scoped engagement letters.

Market-infrastructure researchers

Academics and policy researchers studying post-Dodd-Frank swap venues use SBSEF-W filings as the canonical exit record. They join file number, CIK, and effective date with corresponding registration filings to build venue entry-exit panels, and code wind-down narratives for evidence of consolidation or migration to affiliates.

Competitor venues and product strategy teams

Strategy and regulatory-affairs staff at active SBSEFs and adjacent venue operators treat withdrawals as competitive intelligence: freed-up market share, liquidity migration, and hiring signals. They focus on entity identity, effective date, and wind-down language indicating whether the business is shuttered, sold, or absorbed.

SEC staff as downstream consumers

Enforcement, examinations, and policy staff use the structured EDGAR record to reconstruct a registrant's status timeline — relevant to misconduct allegations spanning deregistration — and to assess how Regulation SE operates in practice for staff statements and rulemaking analyses.

Buy-side and sell-side operations

Connectivity, onboarding, and counterparty-data teams at dealers and asset managers update venue master files when an SBSEF deregisters. They key on legal name, CIK, effective date, and any language about treatment of open contracts to drive static-data updates, give-up and clearing reviews, and trading-desk notifications.

Reference- and regulatory-data vendors

Vendors maintaining registered-entity directories, LEI mappings, and venue codes ingest the metadata header and parse primary_doc.xml to flip entity status as of the effective date. Output feeds compliance systems, KYC tooling, and trade-reporting validators.

Participant compliance and surveillance

Compliance officers at firms routing to security-based swap venues use the effective date and file number to update pre-trade venue eligibility checks, best-execution policies, and reporting routing tables, and to evidence prompt control updates in exams.

Trade-press and policy analysts

Specialist derivatives reporters and policy researchers at industry associations and think tanks use SBSEF-W as the verifiable source for venue-exit coverage, focusing on identity, effective date, and any contextual narrative in primary_doc.xml.

M&A and corporate development advisers

Deal teams working on transactions involving swap-trading venues or their parents pull SBSEF-W records into regulatory due diligence — effective date, signatory, and wind-down representations feed transaction chronologies, disclosure schedules, and integration plans.

Specific Use Cases

Form SBSEF-W records are compact, but they support a small set of concrete workflows tied to venue deregistration events.

Building an SBSEF venue lifecycle panel

Join entities.fileNo (the 039- series SBSEF registration number) and entities.cik from metadata.json against the original Form SBSEF registration filings and any intervening amendments to assemble entry-to-exit panels for every security-based swap execution facility. The filedAt timestamp anchors the exit date in the panel, enabling duration analysis, post-Regulation-SE survival statistics, and consolidation studies.

Flipping venue status in reference-data systems

Reference-data vendors and dealer onboarding teams parse metadata.json for companyName, cik, fileNo, and filedAt, then propagate a deregistered status to LEI mappings, venue master files, and trade-reporting validators. The accession folder is monitored monthly inside the YYYY-MM/ ZIP layout to trigger downstream updates to KYC tooling, pre-trade venue eligibility checks, and best-execution routing tables.

Drafting precedent for deregistration counsel

Derivatives counsel preparing a withdrawal package pull prior xslSBSEF-W_X01/primary_doc.xml renderings as drafting precedents for cover-page presentation, signatory format, and the gap between EDGAR acceptance (filedAt) and effective date. The collection of prior filings supports filing-sequencing memos and engagement letter scoping for SBSEF clients winding down operations.

Reconstructing registrant status timelines for SEC staff and enforcement

Examinations and enforcement staff use the accession-keyed record together with the original SBSEF and any amendments to reconstruct a venue's registered-status timeline around the alleged conduct window. The combination of accessionNo, fileNo, filedAt, and the LIVE/TEST flag (filtering to liveTestFlag == LIVE) gives an authoritative deregistration anchor for staff statements, rulemaking impact reviews, and case chronologies.

Competitor and trade-press monitoring of venue exits

Strategy teams at competing SBSEFs and specialist derivatives reporters watch the monthly ZIP for new accession folders to detect exits in near real time. The HTML cover page renders companyName, CIK, and the LIVE/TEST flag for fast verification, while filedAt and any wind-down language in the rendered view feed competitive briefings on freed-up market share and source citations in published coverage.

M&A regulatory due diligence

Deal teams advising on transactions involving an SBSEF or its parent extract the accession, signatory credentials, and wind-down representations from primary_doc.xml to populate transaction chronologies, regulatory disclosure schedules, and post-closing integration timelines. The fileNo linkage back to the original SBSEF registration documents the full venue history in the diligence binder.

Dataset Access

The SEC Form SBSEF-W Files Dataset is available through three access methods: a JSON metadata endpoint, a full archive download, and per-container downloads.

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

This endpoint returns metadata about the dataset, including its name, description, last update timestamp, earliest sample date (2024-10-01), total record count and size, covered form types (SBSEF-W), container format (ZIP), inner file types (XML, JSON), the full dataset download URL, and the list of all container files with per-container size, record count, updated timestamp, and download URL. Use this endpoint to monitor which containers were updated in the most recent refresh run and to decide which containers to download incrementally on a daily basis. This endpoint does not require an API key.

Example response:

          1
          {
        

          2
            "datasetId": "1f13365b-9ae0-6aa0-9304-5a558cbd93ef",
        

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

          4
            "name": "Form SBSEF-W Files Dataset",
        

          5
            "updatedAt": "2026-04-16T09:06:09.920Z",
        

          6
            "earliestSampleDate": "2024-10-01",
        

          7
            "totalRecords": 2,
        

          8
            "totalSize": 2566,
        

          9
            "formTypes": ["SBSEF-W"],
        

          10
            "containerFormat": "ZIP",
        

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

          12
            "containers": [
        

          13
              {
        

          14
                "downloadUrl": "https://api.sec-api.io/datasets/form-sbsefw-files/2024/2024-10.zip",
        

          15
                "key": "2024/2024-10.zip",
        

          16
                "size": 2566,
        

          17
                "records": 2,
        

          18
                "updatedAt": "2026-04-16T09:06:09.920Z"
        

          19
              }
        

          20
            ]
        

          21
          }
        

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

Downloads the complete dataset as a single ZIP archive containing all monthly container files. This endpoint requires an API key.

Download Single Container: https://api.sec-api.io/datasets/form-sbsefw-files/2024/2024-10.zip?token=YOUR_API_KEY

Downloads one individual monthly container instead of the entire dataset, which is useful for incremental updates or targeted retrieval of a specific time period. This endpoint requires an API key.

Frequently Asked Questions

What form does this dataset cover?

The dataset covers Form SBSEF-W, a notice of withdrawal from registration as a security-based swap execution facility, filed under Section 3D of the Securities Exchange Act of 1934 and Regulation SE. It is the withdrawal counterpart to Form SBSEF, the registration application.

What does one record in this dataset represent?

One record corresponds to one EDGAR submission of Form SBSEF-W, identified by a unique accession number. Each record is materialized as an accession-numbered subfolder containing three files: metadata.json, primary_doc.xml, and the XSL-rendered HTML at xslSBSEF-W_X01/primary_doc.xml.

Who is required to file Form SBSEF-W?

The filer is always a security-based swap execution facility — a trading platform registered with the SEC under Section 3D, or an applicant whose registration is pending. Dealers, major participants, eligible contract participants, and clearing agencies that use the platform are not filers, even though a withdrawal affects their venue access.

When is Form SBSEF-W filed?

The form is event-driven and has no periodic schedule. It is filed when a registered SBSEF (or applicant) elects to discontinue its registered status — for example, on a wind-down, an affiliate consolidation, a migration to a CFTC-registered SEF, abandonment of a pending application, or a corporate restructuring or sale. The filer specifies a proposed effective date, and the Commission may accept, postpone, accelerate, or condition that date under the Section 3D public-interest standard.

What time period does the dataset cover?

Coverage starts in October 2024, when Regulation SE and the SBSEF registration regime became operational, and extends to the present. No paper or pre-EDGAR analogue exists because the registration category itself did not exist before then.

What file format is the dataset distributed in?

The dataset is distributed as monthly ZIP containers organized by year (for example, 2024/2024-10.zip). Inside each container, every filing occupies an accession-numbered subfolder with metadata.json (JSON) and two XML files (the structured submission body and its XSL-rendered HTML view).

How does this dataset differ from CFTC SEF withdrawals or Form ADV-W?

CFTC SEF withdrawals are filed with the CFTC (not EDGAR) and concern non-security-based swaps such as broad-based index, rates, FX, and commodity products; a dually registered venue must file both, and neither substitutes for the other. Form ADV-W is a parallel withdrawal form for investment advisers and covers advisory client relationships and custody rather than venue operations. SBSEF-W is the only SEC dataset that captures the deregistration of a security-based swap execution facility.