The Form SBSE-W Files Dataset is a structured collection of every Form SBSE-W submission accepted by EDGAR — the dedicated request for withdrawal from registration filed by security-based swap dealers (SBSDs) and major security-based swap participants (MSBSPs) under Section 15F of the Securities Exchange Act of 1934 and Rules 15Fb1-1 through 15Fb6-2. One record is one EDGAR accession: a single firm's request to exit its Section 15F registration, packaged with the structured XML form payload, a JSON submission envelope, and EDGAR's XSL-rendered HTML view of the same payload. The dataset is filed by the registrant itself — signed by an authorized officer or principal of the SBSD or MSBSP — and is event-driven rather than periodic, produced only when a registered entity elects to deregister. Coverage begins on 2024-10-01, reflecting the first wave of registrants exiting several years after the November 1, 2021 Section 15F registration compliance date, and continues with each subsequent EDGAR filing.
Programmatically retrieve the full list of dataset archive files, download URLs and dataset metadata.
Dataset Index JSON API
Download the entire dataset as a single archive file.
Download Entire Dataset:
Download a single container file (e.g. monthly archive) from the dataset.
Download Single Container:
The Form SBSE-W Files Dataset captures the entire EDGAR filing population of Form SBSE-W, the SEC's single deregistration form for entities previously registered as a security-based swap dealer or major security-based swap participant under Section 15F of the Exchange Act. Each submission supplies the Commission with the information needed to evaluate whether withdrawal should be permitted: the firm's identifying particulars, the registration category being withdrawn from, the date the firm ceased its security-based swap business, the reason(s) for withdrawing, whether the firm continues to hold segregated counterparty collateral, whether it remains subject to investment-related investigations, customer-initiated complaints, or private civil litigation, and where the firm's books and records will be kept after deregistration.
Form SBSE-W has only ever existed as a structured EDGAR submission, so the dataset has a uniform anatomy across its entire time range with no legacy ASCII or pre-XML era to reconcile. The dataset is distributed in a ZIP container format, with each record materializing as a folder named after the accession number (dashes stripped) placed under a YYYY-MM/ monthly directory. The file types found inside a record are XML (the structured form payload and the XSL-rendered HTML view served under an .xml extension) and JSON (the EDGAR submission envelope).
One record in this dataset is a single EDGAR submission of Form SBSE-W identified by an accession number. Each record materializes on disk as a folder whose name is the accession number with dashes stripped (for example 000082446824000006 for accession 0000824468-24-000006), placed under a YYYY-MM/ directory inside a monthly ZIP container. The folder packages every non-image artifact EDGAR received or produced for that filing: a JSON submission envelope, the structured XML form payload, and the EDGAR XSL-rendered HTML view of that same payload. A record therefore captures both the submission-context metadata and the full machine-readable content of one request to withdraw from registration as a Security-based Swap Dealer (SBSD) or Major Security-based Swap Participant (MSBSP).
Each accession folder contains exactly three artifacts, and no others (image files in the original EDGAR submission are stripped from this dataset):
metadata.json — the EDGAR submission envelope as a JSON object, capturing form type, accession number, filer entity identifiers, timestamps, EDGAR-side URLs, and an enumeration of the documents in the submission.primary_doc.xml — the structured form data, an XML instance rooted at <edgarSubmission> in the EDGAR namespace http://www.sec.gov/edgar/sbse/sbsewfiler, with the shared common namespace http://www.sec.gov/edgar/common used for address sub-elements.xslSBSE-W_X01/primary_doc.xml — the HTML rendering produced by EDGAR's SBSE-W_X01 XSL stylesheet, served under an .xml extension but functionally an HTML representation of the same fields suitable for human reading.The two primary_doc.xml files convey the same content in two surfaces: one parseable, one presentational. The JSON envelope sits one layer above the form and describes the submission itself rather than the form payload.
metadata.json envelopeThe JSON object characterizes the EDGAR submission. The fields that carry intentional structured meaning are:
formType — the form code, always SBSE-W in this dataset.accessionNo — the EDGAR accession number in dashed form (e.g. 0000824468-24-000006).effectivenessDate — the EDGAR effectiveness date of the filing (ISO date).filedAt — the timestamp at which EDGAR accepted the submission, including a timezone offset (ISO-8601 with offset).description — a short EDGAR description string.linkToFilingDetails, linkToTxt, linkToHtml, linkToXbrl — URLs back to the EDGAR-rendered form, the complete .txt submission, the EDGAR filing index page, and any XBRL data. Form SBSE-W is not an XBRL-tagged form, so linkToXbrl is present in the schema for consistency but is not populated for SBSE-W filings.documentFormatFiles — an array of document records, each containing sequence, size, documentUrl, type, and sometimes description. For an SBSE-W submission this enumerates the rendered XSL view, the raw primary_doc.xml, and the complete submission text file.entities — an array of filer entity records. Each entry carries act (the statute under which the form is filed, typically 34 for the Exchange Act), cik, fileNo (the firm's SEC file number), irsNo, companyName (including the EDGAR role suffix such as (Filer)), type (the submission type), and filmNo (the EDGAR film number).seriesAndClassesContractsInformation and dataFiles — present for schema consistency but empty for SBSE-W filings (these fields apply to investment-company and XBRL-bearing form types).id — an internal record identifier hash.primary_doc.xmlThe XML instance is split into a <headerData> block describing submission-time credentials and flags, and a <formData> block carrying the form's substantive content.
<headerData> contains:
<submissionType> — always SBSE-W.<filerInfo> — wraps <filer><filerCredentials> with <filerCik> (zero-padded CIK) and <filerCcc> (the EDGAR CCC password, redacted in the dataset), and a <flags> element exposing <returnCopyFlag> and <overrideInternetFlag> as booleans.<formData> contains two children: <sbseW> (the form body) and <execution> (the signature block).
The <sbseW> body captures the substantive disclosures of the form, in the order in which they appear:
<fullName> — the full legal name of the SBSD or MSBSP.<irsEmplIdentNo> — the IRS Employer Identification Number, hyphenated (e.g. 13-5015677).<secFileNumber> — the firm's SEC file number (e.g. 026-00191).<mainAddress> — the firm's principal address, built from the shared common namespace as com:street1, com:city, com:stateOrCountry (two-character US state or country code), and com:zipCode.<telephoneNumber> — the firm's principal phone number.<registrationType> — the registration category being withdrawn from, taking values such as Security-based Swap Dealer or Major Security-based Swap Participant.<dateCeasedBusiness> — the date the firm ceased its security-based swap business, formatted MM-DD-YYYY.<reasonsToWithdraw> — a container holding one or more <reasonToWithdraw> children. Each value is a free-form string mirroring the checkbox labels on the paper form (for example Ceasing business as a security-based swap dealer, Winding down all business, or No longer doing security-based swap business in U.S.). Multiple reasons may be selected on a single filing.<isHoldCollateral> — a Y/N flag indicating whether the entity continues to hold segregated counterparty collateral after ceasing business.<isInvestigation> — a Y/N flag indicating whether the entity is the subject of any investment-related investigation.<isComplaint> — a Y/N flag indicating whether the entity is subject to any customer-initiated complaint.<islitigation> — a Y/N flag indicating whether the entity is subject to private civil litigation. The lowercase l after is is the schema-defined element name and is not a transcription error.<firmOrIndividual> — selects whether the books-and-records custodian is a Firm or an Individual.<firmName> — the name of the firm (or individual) that will take custody of the books and records after deregistration.<personAddress> — the custodian's address, reusing the same com:street1 / com:city / com:stateOrCountry / com:zipCode structure as <mainAddress>.<personTelephoneNumber> — the custodian's phone number.The <execution> block carries the signature certification:
<date> — execution date in MM-DD-YYYY form.<nameOfPersonSigning> — printed name of the signing officer.<signature> — the signature value, which in EDGAR practice is typed text, typically matching the printed name rather than image data.<titleOfPersonSigning> — title of the signing officer (e.g. Co-President GWM and President UBS Americas).xslSBSE-W_X01/primary_doc.xmlThis file is the HTML presentation of the same record, produced by the EDGAR stylesheet whose identifier is SBSE-W_X01. It opens with the OMB header and the title "FORM SBSE-W: Request for Withdrawal from Registration as a Security-based Swap Dealer or Major Security-based Swap Participant", followed by a Filer Information block (Filer CIK, masked Filer CCC, LIVE/TEST indicator, contact information). The body lays out the numbered sections of the form: (1) identifying information including legal name, IRS EIN, SEC file number, main address, and telephone number; (2) the registration category being withdrawn from; (3) the date the firm ceased business; (4) the selected reasons for withdrawal, with checkbox state rendered as inline images; (5) the segregated-collateral question; (6) the trio of investigation, complaint, and litigation questions; and (7) the name, address, and phone number of the books-and-records custodian. An EXECUTION section reproduces the certification language followed by the signing date, printed name, signature value, and title. The rendered view conveys no information beyond what the structured XML already encodes; it exists for human inspection and parity with the EDGAR-served rendering.
Image files from the original EDGAR submission — typically signature-block JPEGs or PNGs embedded in the rendered view — are not included in this dataset. Because the rendered HTML references those images relative to its own folder, signature graphics will resolve as missing when the HTML is opened offline; however, every textual field they accompany is preserved in both primary_doc.xml files. EDGAR-side amendments to a Form SBSE-W (if any) are filed under separate accession numbers and therefore appear as separate records rather than being merged into the original filing. The complete submission .txt wrapper that EDGAR distributes for the filing is referenced via linkToTxt in the metadata but is not duplicated inside the record folder.
Several anatomical nuances matter when parsing or analyzing the data. First, the <islitigation> element name is deliberately lower-cased after is in the EDGAR schema and must be matched verbatim rather than normalized to camelCase. Second, the <reasonsToWithdraw> container can hold multiple <reasonToWithdraw> children, so consumers should iterate rather than read a single value. Third, address sub-elements live in the shared http://www.sec.gov/edgar/common namespace, distinct from the SBSE-W namespace that wraps the rest of the form, which matters for namespace-aware XPath. Fourth, both <mainAddress> and <personAddress> use the same address schema, allowing uniform parsing. Fifth, date fields inside the form (<dateCeasedBusiness>, <execution><date>) use the MM-DD-YYYY convention, whereas metadata.json dates (effectivenessDate, filedAt) follow ISO-8601, so consumers must reconcile the two formats. Sixth, the <signature> element holds a typed string rather than image data, so any handwritten signature in the original PDF rendering is conveyed in image form only and is therefore not present in the dataset. Finally, because Form SBSE-W has been a structured XML form since its introduction under the Section 15F registration regime, record anatomy is uniform across the dataset's time range, with no legacy ASCII or pre-XML era to account for.
Each record in the Form SBSE-W Files Dataset is one EDGAR submission by a registered security-based swap entity requesting withdrawal from its Section 15F registration. The filer is always the registrant itself, signed by an authorized officer or principal. The reporting population is limited to two classes defined under Title VII of the Dodd-Frank Act and Section 15F of the Securities Exchange Act of 1934:
Only entities previously registered on Form SBSE, Form SBSE-A, or Form SBSE-BD can file Form SBSE-W. Counterparties, customers, associated persons, and affiliates are not filers, even when they appear in the form's disclosures about pending claims, custody arrangements, or corporate relationships.
Form SBSE-W is event-driven, not periodic. It is filed when a registered SBSD or MSBSP elects to exit the regime. Typical triggers include:
There is no quarterly, annual, or transactional cadence. The registrant typically files in advance of the desired effective date. Withdrawal does not take effect automatically: the Commission may delay or condition effectiveness if there are unresolved customer claims, complaints, or regulatory matters, and the registrant remains subject to all Section 15F obligations (capital, margin, recordkeeping, business conduct, reporting) until withdrawal is granted.
The regulatory basis is Section 15F of the Exchange Act (added by Section 764 of Dodd-Frank) and Exchange Act Rules 15Fb1-1 through 15Fb6-2, with Rule 15Fb3-3 prescribing Form SBSE-W as the means of requesting withdrawal. The form has only ever existed as an EDGAR submission; the dataset begins in October 2024, reflecting the first wave of registrants exiting several years after the November 1, 2021 registration compliance date.
Form SBSE-W is the exit filing in a narrow Section 15F registration regime for security-based swap dealers and major security-based swap participants. The most informative comparisons are the other forms in the SBSE family, the parallel withdrawal forms used by adjacent registrant classes (broker-dealers and investment advisers), and the CFTC-side withdrawal mechanism for dually registered swap entities.
SBSE is the principal Section 15F registration application for entities that are neither broker-dealers nor CFTC-registered swap dealers. SBSE opens the registration relationship and collects extensive identifying, ownership, control, disciplinary, and disclosure information; SBSE-W closes that relationship and collects only what is needed to evaluate whether withdrawal is appropriate. SBSE is broad, long, and filed at entry; SBSE-W is short, narrow, and filed at exit. Together they bracket the registration lifecycle.
SBSE-A is the abbreviated Section 15F registration form for entities already registered with the CFTC as swap dealers or major swap participants, relying on referenced CFTC/NFA filings. It is an entry form contingent on dual registration. SBSE-W applies uniformly to all withdrawing SBSDs/MSBSPs regardless of how they registered; there is no abbreviated withdrawal track. Overlap with SBSE-W is minimal.
SBSE-BD is the short-form Section 15F registration used by entities already registered as broker-dealers, incorporating the Form BD record by reference. Like SBSE-A, it is an entry form for a dually registered firm. A firm withdrawing via SBSE-W remains a broker-dealer unless it also files Form BDW; the SEC's broker-dealer and SBSD withdrawal regimes are independent.
Form SBSE-C carries the Rule 15Fb2-1(b) senior officer compliance certifications and is an in-life attestation tied to continued registration. SBSE-W is an event-driven, terminal filing that ends that registration. SBSE-C populates the registration file during the registered period; SBSE-W closes it.
Form BDW is the closest structural analog to SBSE-W outside the SBSE family. Both collect identifying information, withdrawal effective date, and disclosures regarding pending complaints, arbitrations, judgments, and the disposition of customer funds and securities. They diverge on:
A dually registered firm exiting both businesses must file each form separately.
Form ADV-W is the conceptually parallel withdrawal form for investment advisers under the Advisers Act. The differences from SBSE-W mirror those of BDW: a different statutory regime, a different filer population, IARD-based filing rather than EDGAR, and very different volumes. ADV-W also serves state-registered advisers; SBSE-W has no state analog because SBSD/MSBSP registration is purely federal.
For dually registered swap entities, the CFTC/NFA withdrawal procedure is the cross-agency counterpart to SBSE-W. The two are substantively similar in purpose but governed by separate regulators, filed through different systems, and not interchangeable. A firm exiting both businesses files at each agency.
The Form SBSE-W Files Dataset is defined by the intersection of three narrow attributes: a single terminal-event filing type, a tightly bounded registrant population (only currently registered SBSDs and MSBSPs), and a very small filing universe since Section 15F became operational. Other SBSE-family forms cover entry and in-life phases of the same registrants but contain materially different information. BDW and ADV-W are the right structural analogs for other registrant classes but omit the SBS-specific Section 15F representations. SBSE-W is therefore the only SEC dataset that records the end of an SBSD or MSBSP registration relationship.
Form SBSE-W records the withdrawal of a security-based swap dealer or major security-based swap participant from Section 15F registration. The filing is rare but consequential, and a defined set of roles work with it.
In-house compliance officers and registration specialists use peer filings as templates when preparing their own withdrawal. They focus on the wording of custody representations, pending-claim and unresolved-complaint disclosures, effective-date language, and certification blocks. The dataset informs internal sign-off workflows and the timing of board approvals before submission.
Examiners and registration analysts track the population of withdrawing entities, verify continuity with prior SBSE filings on the same CIK and file number, and review custody and complaint disclosures. The record supports decisions on whether withdrawal can become effective and what follow-up is required before deregistration.
External counsel and in-house derivatives lawyers reference the dataset when advising on deregistration mechanics, reorganizations, and business-line exits. They study representation language, certification formats, and filing sequencing, and rely on prior filings in enforcement and dispute contexts where withdrawal representations become material.
Credit officers and derivatives ops leads at firms facing SBSDs or MSBSPs use withdrawal filings to flag exposure changes. They map legal name, CIK, file number, and requested effective date to bilateral exposures, ISDA relationships, and collateral arrangements, and use custody and complaint disclosures to assess novation or close-out needs.
Academic economists and analysts at policy organizations and trade associations measure exit rates from Section 15F registration, correlate withdrawals with rule changes, and study concentration in regulated SBS dealing. Outputs include working papers, comment letters, and briefings to rulemakers.
Strategy teams at competing dealers, prime brokers, and clearing firms monitor when a rival exits the regulated SBS business. They use registrant identity, withdrawal timing, and customer-facing wind-down disclosures to plan client coverage for displaced flow and adjust pricing or capacity.
Audit teams benchmark how withdrawal controls and custody, securities, and complaint representations are evidenced at peers. They focus on certifications, signature blocks, and consistency between SBSE-W disclosures and other regulatory and financial records to support control testing around wind-down procedures.
Data engineers extend SEC filing coverage to the SBSE form family and maintain entity-level views of the full registration lifecycle. They use XML and JSON metadata for identifiers, form type, accession number, and effective dates to join withdrawal events to other filings on CIK and file number, and to ground retrieval systems on questions about Section 15F exits.
The Form SBSE-W Files Dataset is small but operationally important wherever Section 15F registration status drives a workflow. The use cases below are the most concrete ways teams put it to work.
Drafting a withdrawal filing from peer precedents. Compliance and registration teams at SBSDs and MSBSPs pull prior primary_doc.xml payloads to model the wording of <reasonsToWithdraw> entries, <isHoldCollateral>/<isInvestigation>/<isComplaint>/<islitigation> representations, and the <execution> certification block. The reused language and field combinations feed internal drafting checklists and board-approval packages before EDGAR submission.
Tracking SBSD/MSBSP population changes over time. Market structure researchers and SEC registration staff parse metadata.json (filedAt, effectivenessDate, entities[].cik, fileNo) together with <dateCeasedBusiness> and <registrationType> to build a longitudinal census of exits from Section 15F registration. The resulting time series supports rule-impact studies, comment letters, and internal staff briefings.
Mapping counterparty wind-down to bilateral exposures. Derivatives operations and credit teams join <fullName>, <irsEmplIdentNo>, <secFileNumber>, and the EDGAR CIK from a withdrawal record to internal ISDA, CSA, and collateral inventories. <isHoldCollateral>, <firmName>, and <personAddress> (books-and-records custodian) then drive close-out, novation, and recordkeeping-contact workflows for affected trades.
Linking withdrawals to the full SBSE registration lifecycle. Data engineering and RAG/LLM teams use accessionNo, cik, and fileNo from metadata.json to stitch each SBSE-W record to the same firm's earlier SBSE, SBSE-A, SBSE-BD, and SBSE-C filings. The resulting entity-level lifecycle view grounds retrieval systems answering questions about when and why specific SBSDs or MSBSPs exited.
Monitoring open investigations, complaints, and litigation at exit. Examination staff, auditors, and external counsel extract the <isInvestigation>, <isComplaint>, and <islitigation> flags alongside <dateCeasedBusiness> to flag filings that warrant follow-up before withdrawal can be permitted. The same fields support audit testing that withdrawal-time disclosures are consistent with internal complaint logs and litigation registers.
Competitive-intelligence alerts on rival SBS exits. Strategy teams at competing dealers and prime brokers watch the dataset for new accession folders under recent YYYY-MM/ directories, then read <fullName>, <registrationType>, <dateCeasedBusiness>, and the selected <reasonToWithdraw> strings to brief sales and coverage teams on displaced flow and to adjust pricing or capacity for affected client segments.
Dataset Index JSON API: https://api.sec-api.io/datasets/form-sbsew-files.json
Returns dataset metadata and the list of available container files. The response includes the dataset name, description, last updated timestamp, earliest sample date (2024-10-01), total records and total size, form types covered (SBSE-W), container format (ZIP), and contained file types (XML, JSON). It also returns the full dataset download URL and, for every container, its key, size, record count, last updated timestamp, and a direct download URL. Poll this endpoint to detect which containers changed in the most recent refresh and decide which to download on a day-by-day basis.
This endpoint does not require an API key.
Example response:
1
{
2
"datasetId": "1f13365b-9ae0-6a8b-ab7b-1b30c034f99e",
3
"datasetDownloadUrl": "https://api.sec-api.io/datasets/form-sbsew-files.zip",
4
"name": "Form SBSE-W Files Dataset",
5
"updatedAt": "2026-04-16T09:00:54.814Z",
6
"earliestSampleDate": "2024-10-01",
7
"totalRecords": 8,
8
"totalSize": 21684,
9
"formTypes": ["SBSE-W"],
10
"containerFormat": "ZIP",
11
"fileTypes": ["XML", "JSON"],
12
"containers": [
13
{
14
"downloadUrl": "https://api.sec-api.io/datasets/form-sbsew-files/2026/2026-03.zip",
15
"key": "2026/2026-03.zip",
16
"size": 5421,
17
"records": 2,
18
"updatedAt": "2026-04-16T09:00:54.814Z"
19
}
20
]
21
}
Download Entire Dataset: https://api.sec-api.io/datasets/form-sbsew-files.zip?token=YOUR_API_KEY
Downloads the complete Form SBSE-W Files Dataset as a single ZIP archive containing all monthly containers from October 2024 to present. This endpoint requires an API key.
Download Single Container: https://api.sec-api.io/datasets/form-sbsew-files/2026/2026-03.zip?token=YOUR_API_KEY
Downloads one monthly container archive instead of the full dataset, which is useful for incremental updates after a new refresh. Replace the year and month segments with the container key returned by the index JSON API. This endpoint requires an API key.
The dataset covers Form SBSE-W, the request for withdrawal from registration filed by security-based swap dealers and major security-based swap participants under Section 15F of the Securities Exchange Act of 1934 and Rules 15Fb1-1 through 15Fb6-2. It is the SEC's single deregistration form for the SBSD/MSBSP regime.
One record is a single EDGAR submission of Form SBSE-W identified by an accession number, materialized as a folder containing three artifacts: a metadata.json submission envelope, the structured primary_doc.xml form payload, and an xslSBSE-W_X01/primary_doc.xml HTML rendering produced by the EDGAR XSL stylesheet.
Only entities previously registered as a security-based swap dealer or major security-based swap participant under Section 15F — typically on Form SBSE, Form SBSE-A, or Form SBSE-BD — can file Form SBSE-W. The filer is always the registrant itself, signed by an authorized officer or principal. Counterparties, customers, and affiliates are not filers.
The filing is event-driven, not periodic. A registrant files it when electing to exit the Section 15F regime — for example, when ceasing security-based swap activity, falling below the SBSD de minimis or MSBSP threshold, undergoing corporate reorganization, or transferring its swap book. Withdrawal does not take effect automatically; the Commission sets the effective date.
Coverage begins on 2024-10-01, reflecting the first wave of registrants exiting several years after the November 1, 2021 Section 15F registration compliance date, and continues through the present with each new EDGAR submission.
The dataset is distributed as monthly ZIP containers organized under YYYY-MM/ directories. Inside each container, every record folder contains XML files (the structured form payload and an XSL-rendered HTML view served under an .xml extension) and a JSON file (the EDGAR submission envelope).
Form BDW is the broker-dealer withdrawal form under Section 15 of the Exchange Act, filed through CRD/Web CRD. Form SBSE-W is the security-based swap dealer/major participant withdrawal form under Section 15F, filed through EDGAR. A firm that is both a broker-dealer and an SBSD must file each form separately to exit each regime; the two withdrawals are independent.