Form SBSE-BD Files Dataset

The Form SBSE-BD Files dataset contains every Form SBSE-BD and Form SBSE-BD/A application submitted to EDGAR — the SEC's registration filing used by an entity that is already registered (or concurrently registering) as a broker or dealer to register, under Section 15F(b) of the Securities Exchange Act of 1934, as a security-based swap dealer (SBSD) or major security-based swap participant (MSBSP). One record corresponds to a single EDGAR accession (an initial SBSE-BD application or an SBSE-BD/A amendment) and is materialized as a per-accession folder containing the structured XML payload, an XSL-rendered HTML view, a JSON metadata envelope describing the submission, and any PDF exhibits. Records are grouped by month of acceptance and distributed in monthly ZIP containers. The dataset begins on October 1, 2021 — the SEC's compliance date for Section 15F registration — and continues to the present.

Dataset APIs

Dataset Files

What This Dataset Contains

Form SBSE-BD is the SEC's registration application for an SBSD or MSBSP that is also registered, or in the process of registering, as a broker or dealer with the Commission under Section 15F(b) of the Securities Exchange Act of 1934. It sits alongside two sibling forms in the same Section 15F(b) registration family: Form SBSE (the general application) and Form SBSE-A (the application for entities already registered with the CFTC as swap dealers or major swap participants). SBSE-BD is the streamlined variant for broker-dealer applicants, on the rationale that the Commission already collects extensive identification, disciplinary, and ownership information about broker-dealers through Form BD; SBSE-BD therefore captures only the incremental information needed to layer SBSD/MSBSP registration on top of an existing or pending broker-dealer registration.

The substantive form has a small, fixed structure organized as numbered items: applicant identity and key personnel contacts, the registration capacity being claimed (SBSD vs. MSBSP), regulatory-status questions about prudential supervision and OTC derivatives dealer status, a free-text business description, a foreign-regulator question, an execution/signature block, and Schedule F for nonresident applicants and for itemizing foreign regulatory registrations. Form SBSE-BD/A is the amendment variant of the same form and carries the same item set; amendments are used both for material corrections and for ongoing maintenance of registration data.

The dataset includes all Form SBSE-BD and Form SBSE-BD/A filings submitted to EDGAR from October 2021 to present. For each accession, the dataset bundles a JSON metadata envelope and every document EDGAR accepted as part of the submission, except image files. Records are distributed in monthly ZIP containers under the form-sbsebd-files/ prefix; the file types found in the dataset are XML, JSON, and PDF.

Content Structure of a Single Record

1. What one record represents

One record in the Form SBSE-BD Files dataset is a single EDGAR accession — that is, one Form SBSE-BD or Form SBSE-BD/A submission filed by a broker-dealer applying to register, or amending an existing registration, as a security-based swap dealer (SBSD) or major security-based swap participant (MSBSP). The record is materialized as a per-accession folder named after the 18-digit numeric accession identifier (the dashed EDGAR accession number with dashes stripped), e.g. 000170882825000041. Inside that folder sit every artifact EDGAR accepted as part of the submission, except image files, plus a metadata.json envelope summarizing the submission at the EDGAR level.

Records are grouped by year and by YYYY-MM month of acceptance, and distributed in monthly ZIP containers under the form-sbsebd-files/ prefix. Initial filings (form type SBSE-BD) and amendments (form type SBSE-BD/A) are first-class records of identical structure; the only fixed differences are the value of formType in the metadata envelope and the value of submissionType in the XML payload.

2. Top-level layout of one record

A record folder contains three categories of artifact:

1. metadata.json — a JSON envelope describing the EDGAR submission as a whole: form type, accession number, acceptance timestamp, filer entities, and a manifest of every document file in the submission.
2. primary_doc.xml — a structured XML payload carrying the form's data fields in EDGAR's sbsebdfiler namespace. This is the canonical, machine-parseable copy of the form's contents.
3. xslSBSE-BD_X01/primary_doc.xml — a rendered HTML view of the same form, produced by EDGAR's SBSE-BD_X01 XSL stylesheet, intended for human reading. Despite the .xml extension and lingering namespace declarations, it is functionally an XHTML document with inline CSS and <img> references to checkbox/radio-button assets.

Some records additionally contain PDF attachments — typically Schedule F supporting material for nonresident applicants, signed certifications, or corroborating registration documents from foreign regulators. The file-types found in the dataset are XML, JSON, and PDF; image files (GIF, JPG, PNG) attached to EDGAR submissions are excluded from the dataset copy.

The accession folder is therefore the unit of record. All record-level keys derive from metadata.json.accessionNo; the folder name is the dashless 18-digit form of that same accession number.

3. Component-by-component breakdown

3.1 metadata.json — submission envelope

metadata.json is a single JSON object describing the EDGAR submission at the accession level. Top-level fields:

• formType — "SBSE-BD" for an initial application or "SBSE-BD/A" for an amendment.
• accessionNo — canonical EDGAR accession number in dashed form (e.g., 0001708828-25-000041).
• filedAt — ISO 8601 acceptance timestamp with Eastern-time offset (e.g., 2025-12-22T09:45:38-05:00).
• description — short human-readable submission description (e.g., "Form SBSE-BD/A - [Amend]").
• linkToFilingDetails — URL to the rendered HTML view of the filing on EDGAR.
• linkToHtml — URL to the EDGAR filing index page.
• linkToTxt — URL to the complete-submission .txt bundle that EDGAR generates server-side.
• linkToXbrl — empty for SBSE-BD.
• dataFiles — empty for SBSE-BD.
• seriesAndClassesContractsInformation — empty for SBSE-BD; the form is not a series/class registration.
• documentFormatFiles[] — array of document descriptors, one per file in the EDGAR submission.
• entities[] — array of filer descriptors, one per filing entity.
• id — a dataset-internal identifier (hex string).

Each entry in documentFormatFiles[] describes a single file in the EDGAR submission with sequence, size (bytes, as a string), documentUrl, type, and an optional description. Typical entries include the rendered XSL view, the raw primary_doc.xml, the complete-submission .txt bundle (described as "Complete submission text file"), and any PDF exhibits with their own document types. A small number of fields are recorded as a single space (" ") when EDGAR did not supply a value — most commonly sequence and type for the complete-submission text bundle, and size for the rendered XSL view.

Each entry in entities[] describes one filer with:

• companyName — legal name with the EDGAR role appended in parentheses, e.g., "CLEAR STREET LLC (Filer)".
• cik — Central Index Key as unpadded digits.
• irsNo — IRS Employer Identification Number (EIN) as digits.
• fileNo — SEC-assigned file number; for SBSE registrants this typically falls in the 026-XXXXX series.
• filmNo — EDGAR film number assigned at acceptance.
• stateOfIncorporation — two-letter state or jurisdiction code.
• fiscalYearEnd — MMDD.
• act — securities act under which the filing is made; "34" denotes the Securities Exchange Act of 1934.
• type — form type as filed.

3.2 primary_doc.xml — raw form payload

The raw XML is an edgarSubmission document under the namespace http://www.sec.gov/edgar/sbse/sbsebdfiler, with shared common types imported from http://www.sec.gov/edgar/common under the conventional com: prefix. The document has two top-level branches: headerData (EDGAR submission credentials and flags) and formData (the substantive form content).

headerData

• submissionType — "SBSE-BD" or "SBSE-BD/A"; mirrors metadata.json.formType.
• filerInfo/filer/filerCredentials/cik — zero-padded ten-digit CIK identifying the filer.
• filerInfo/filer/filerCredentials/ccc — the CIK Confirmation Code used at submission time, always masked as XXXXXXXX in the public dissemination copy. It carries no information for downstream use.
• filerInfo/flags/returnCopyFlag and filerInfo/flags/overrideInternetFlag — boolean strings ("true"/"false") recording EDGAR-level submission options.

formData

The formData branch mirrors the numbered items of the paper SBSE-BD form. It has three substantive children: applicantOne, execution, and scheduleF.

applicantOne carries Items 1 through 7:

• fullApplicantName — legal name of the applicant entity (Item 1).
• crdNo — the applicant's FINRA Central Registration Depository number, linking the SBSE-BD application back to the broker-dealer's CRD record.
• contactEmployee — block describing the person designated to handle questions about this filing, with sub-elements contactEmployeeName/com:firstName and contactEmployeeName/com:lastName, plus title, phone, and emailAddress.
• chiefComplianceOfficer — parallel block identifying the firm's chief compliance officer, structured as officerName/com:firstName and officerName/com:lastName with title, phone, and emailAddress.
• isSwapDealer — Y/N for Item 2A: registering as a security-based swap dealer.
• isSwapParticipant — Y/N for Item 2B: registering as a major security-based swap participant.
• isSubjectToRegulator — Y/N for Item 4: subject to a "prudential regulator" as defined in Section 1a(39) of the Commodity Exchange Act (the OCC, the Federal Reserve, the FDIC, the Farm Credit Administration, or the Federal Housing Finance Agency).
• isDerivativesDealer — Y/N for Item 5: currently registered with the Commission as an OTC derivatives dealer.
• describeBusiness — Item 6, a free-text narrative describing the applicant's business and the rationale for the SBSD/MSBSP registration.
• isForeignRegulatory — Y/N for Item 7: registered with a foreign financial regulatory authority. If Y, the details are itemized in Schedule F Section II.

execution is Item 8, the signature block, with date (in MM-DD-YYYY format), nameOfApplicant, signature, nameOfPersonSigning, and titleOfPersonSigning. It represents the certification, under penalties of perjury, that the information in the application is true, current, and complete.

scheduleF carries Schedule F. Schedule F is the home for nonresident-applicant disclosures and for itemizing foreign regulatory registrations triggered by Item 7. For resident U.S. broker-dealers with no foreign regulatory entries, only applicantName is populated and the schedule serves as a structural placeholder; for nonresident filers and for filers with foreign regulatory registrations, the schedule expands to carry the consent to service of process language, the agent-for-service designation, and the itemized list of foreign regulatory bodies with which the applicant is registered.

Y/N item flags throughout formData are single-character string values, not booleans: Y asserts that the item applies to the applicant, N that it does not.

3.3 xslSBSE-BD_X01/primary_doc.xml — rendered HTML view

This file is the same form, pre-wrapped as an XHTML page by EDGAR's SBSE-BD_X01 stylesheet. It opens with a <!DOCTYPE html> declaration and carries inline CSS plus a <body> rendered as labelled sections that mirror the official paper form layout — page headings such as "SBSE-BD/A: Filer Information", "SBSE-BD/A: Applicant Data - Page 1", and "SBSE-BD/A: EXECUTION". The XSL leaves residual namespace declarations on each block (e.g., xmlns:p="http://www.sec.gov/edgar/sbse/sbsebdfiler"), but the artifact behaves as HTML in a browser. Y/N selections from the raw XML are depicted with <img> references to /Images/radio-checked.jpg, /Images/radio-unchecked.jpg, /Images/box-checked.jpg, and /Images/box-unchecked.jpg.

The data content of this file is fully derivable from the raw primary_doc.xml; the rendered view exists for human readability and for visual fidelity with the form as it appears on EDGAR. The rendered file is several times larger than the raw XML because of inline CSS and decorative markup.

3.4 PDF attachments (when present)

PDF attachments, when included in the original EDGAR submission, sit at the top of the accession folder alongside metadata.json and primary_doc.xml. They are typically used for Schedule F supporting documentation, signed certifications, foreign-regulator letters, or other corroborating material that does not fit inside the structured XML payload. Their presence and document type are recorded as additional entries in the documentFormatFiles[] array of metadata.json. Code that walks a record's folder should not assume only the three standard files are present.

4. Included content

Each record contains the complete EDGAR submission contents needed to reconstruct the filing as the Commission received it: the JSON envelope describing every file and every filer entity, the structured XML carrying the form's items, the XSL-rendered HTML view used to display the form on EDGAR, and any PDF exhibits. The documentFormatFiles[] array in metadata.json is the authoritative manifest of which files belonged to the EDGAR submission, including the server-generated complete-submission .txt bundle (referenced by URL rather than bundled into the folder).

5. Excluded or separate content

• Image files (typically scanned signatures, logos, or photographs accompanying foreign-regulator documentation) are excluded from the dataset copy.
• The complete EDGAR .txt submission bundle is referenced by URL via metadata.json.linkToTxt rather than materialized inside the accession folder. It is a server-side concatenation of the same materials and contains no information not already present in the structured artifacts.
• The CIK Confirmation Code (headerData/filerInfo/filer/filerCredentials/ccc) is masked to XXXXXXXX in the public dissemination copy and carries no usable value.
• Form SBSE and Form SBSE-A submissions — the sibling general and CFTC-paired registration variants — are separate form types and are not part of this dataset; they are distributed in their own dataset slices keyed by their own form-type codes. Form BD itself, which underlies the broker-dealer registration that SBSE-BD is layered on top of, is also distributed separately.

6. Interpretation and extraction notes

• Initial vs. amended filings. formType (in JSON) and submissionType (in XML) distinguish initial registrations (SBSE-BD) from amendments (SBSE-BD/A). Both share an identical schema, so reconstructing a filer's current registration state requires walking the chronological sequence of accessions for that filer and treating each later SBSE-BD/A as an overlay on the prior state, rather than reading a different document layout.
• Cross-reference keys. crdNo is the most reliable cross-reference into FINRA's CRD system and into the applicant's existing Form BD record; cik is the corresponding cross-reference into EDGAR; fileNo (in the 026-XXXXX series) is the SEC-assigned identifier for the SBSE registration itself.
• Namespaces. Substantive elements live under http://www.sec.gov/edgar/sbse/sbsebdfiler; person-name components and other shared types are imported from http://www.sec.gov/edgar/common under the com: prefix. Parsers should bind both namespaces.
• Y/N semantics. Item flags are single-character strings, not booleans. Treat unset or missing flags as not asserted; treat N as an explicit negative assertion that may itself be material (for example, an isSubjectToRegulator=N answer is a substantive disclosure that the applicant is not bank-prudentially supervised).
• Schedule F variability. For nonresident filers and filers with foreign regulatory registrations, scheduleF carries the consent-to-service-of-process language, the agent-for-service designation, and the foreign regulator list — the most distinctive content in the record. For resident U.S. broker-dealers with no foreign registrations, scheduleF is essentially empty (only applicantName populates).
• Extraction guidance. Downstream consumers that need structured form data should parse the raw primary_doc.xml directly. The XSL-rendered HTML view duplicates the same fields wrapped in decorative markup and is appropriate for display, not extraction.
• Sparse-string conventions in documentFormatFiles[]. Some sequence, size, and type fields contain a single space (" ") rather than being absent or null. Parsers should treat a space-only value as "not provided by EDGAR".
• Boilerplate metadata fields. seriesAndClassesContractsInformation, linkToXbrl, and dataFiles are inherited from the shared EDGAR submission metadata schema and are consistently empty for SBSE-BD filings because the form is not a series/class registration and does not carry XBRL tagging. Their presence is structural, not informational.
• Format stability. Form SBSE-BD has been an electronic-only EDGAR filing throughout the period covered by this dataset (October 2021 onward), so the record format has been stable: an XML primary document under the sbsebdfiler namespace, an XSL-rendered HTML companion, and any PDF attachments. There is no pre-XML or ASCII era to reconcile for this form.

Who Files or Publishes This Dataset, and When

Who files the record

Form SBSE-BD is filed by a single, narrow class of applicant: a legal entity that is already registered (or concurrently registering) with the SEC as a broker or dealer under Section 15(b) of the Securities Exchange Act of 1934 and that is applying to register with the Commission as a security-based swap dealer (SBSD) or major security-based swap participant (MSBSP) under Section 15F.

The filer is always the applicant entity itself, signing through a duly authorized officer. Parents, holding companies, control affiliates, and individual associated persons are referenced inside the form but are not the registrant.

The SBSE form family partitions applicants by their other regulatory status:

• Form SBSE — applicant is neither an SEC-registered broker-dealer nor a CFTC-registered swap dealer / major swap participant (longest form).
• Form SBSE-A — applicant is a CFTC-registered swap dealer or major swap participant (shortened to leverage CFTC/NFA filings).
• Form SBSE-BD — applicant is an SEC-registered (or registering) broker or dealer (shortened to leverage the Form BD already on file).

Only the third population appears in this dataset. In practice these filers are dealer-side intermediaries in single-name credit default swaps and equity-based total return swaps — typically large U.S. broker-dealers (often bank-affiliated) and a small number of non-U.S. broker-dealers. A nonresident applicant must additionally submit Schedule F, including appointment of a U.S. agent for service of process and an opinion of counsel on access to books, records, and onsite inspection (Rule 15Fb2-4).

When the record is created or required

Filings are event-driven; there is no periodic cadence comparable to a 10-K or 10-Q. Two trigger types produce records in this dataset:

• Initial application (Form SBSE-BD). Required before the applicant holds itself out as, or acts as, an SBSD or MSBSP above the de minimis thresholds in Rule 3a71-2 (SBSD notional thresholds) or the substantial position thresholds for MSBSPs under Rule 3a67-1 et seq.
• Amendment (Form SBSE-BD/A). Required promptly whenever previously reported information becomes materially inaccurate or incomplete, and at minimum annually to refresh the senior officer and chief compliance officer certifications. Common amendment triggers include changes in control or principal place of business, new disciplinary or regulatory disclosures, changes to associated-person statutory disqualification disclosures, and updates to Schedule F for nonresidents.

Regulatory framework. Section 15F was added to the Exchange Act by Title VII of the Dodd-Frank Wall Street Reform and Consumer Protection Act of 2010. Section 15F(b) requires any person acting as an SBSD or MSBSP to register with the Commission. The SEC implemented this regime through Rules 15Fb1-1 through 15Fb2-4, which prescribe the application form, the conditional registration mechanic, certifications, and nonresident requirements. The SBSE form family was adopted in Release No. 34-75611 (2015), and the SEC set October 6, 2021 as the compliance date by which firms acting above the de minimis levels had to be registered. Initial SBSE-BD applications therefore cluster in late 2021, matching the dataset's earliest records.

Filing channel. SBSE-BD and SBSE-BD/A are submitted electronically through EDGAR using the dedicated SBS submission types. Each filing receives its own accession number and is signed under penalty of federal law. Because EDGAR became the mandated channel concurrently with the 2021 compliance date, there is no pre-EDGAR paper history for this form.

Important distinctions

• Form BD vs. Form SBSE-BD. Form BD remains the broker-dealer registration filing; SBSE-BD is an additional, separate registration that layers SBSD or MSBSP status on top. SBSE-BD does not confer or replace broker-dealer status, and Form BD filings are not in this dataset.
• SBSE vs. SBSE-A vs. SBSE-BD. CFTC-registered swap dealers that are not SEC-registered broker-dealers file SBSE-A; applicants in neither category file the long-form SBSE. Both populations are excluded from this dataset, which is why the SBSE-BD population is small and concentrated in dealer-affiliated entities.
• Withdrawal. A registrant exiting the SBSD/MSBSP regime files Form SBSE-W. Withdrawal filings are not part of this dataset; the SBSE-BD record remains the operative registration document until withdrawal is effected.
• Amendments do not supersede originals. Each SBSE-BD/A is a standalone EDGAR submission with its own accession number; the current state of a registrant's application is the original SBSE-BD plus the chronological stack of SBSE-BD/A amendments.
• Counterparties are not filers. The applicant entity files; its swap counterparties, clients, and individual associated persons are not registrants on the form.
• Nonresident filers. The filer remains the foreign legal entity itself, not its U.S. agent for service of process named in Schedule F.

How This Dataset Differs From Similar Datasets or Filings

Form SBSE-BD sits inside a tightly defined family of Section 15F registration filings for security-based swap (SBS) dealers and major SBS participants. Its closest neighbors are the other SBSE-series forms, the underlying broker-dealer registration it depends on, and the parallel CFTC swap dealer regime.

Form SBSE (standalone SBS entity registration)

Form SBSE is the full, self-contained registration application for SBS dealers and major SBS participants that are neither registered broker-dealers nor registered investment advisers. It carries the complete identifying, ownership, control-person, and disciplinary disclosures.

SBSE-BD addresses the same Section 15F(b) threshold but only for applicants already registered as a broker or dealer. Because those firms have a Form BD on file, SBSE-BD is intentionally stripped down and omits disclosures already present in the BD record. An SBSE filing is therefore materially longer and self-sufficient; an SBSE-BD filing must be read alongside Form BD to reconstruct equivalent content.

Form SBSE-A (SBS entities also registered as investment advisers)

SBSE-A is the IA-registered analog: it piggybacks on Form ADV the same way SBSE-BD piggybacks on Form BD. The three forms partition the SBS-entity population by collateral registration status — SBSE-BD for BD-registered firms, SBSE-A for IA-registered firms, SBSE for everything else — with no overlap at a given moment.

Form SBSE-W (withdrawal of SBS entity registration)

SBSE-W is the terminal, exit-side counterpart: a short notice of cessation rather than a substantive registration package. SBSE-BD and SBSE-BD/A capture entry and ongoing maintenance; SBSE-W captures departure. A complete view of the active BD-registered SBS-entity population requires combining both ends of the lifecycle.

Form SBSE-BD/A versus Form SBSE-BD

SBSE-BD/A filings are amendments to a prior SBSE-BD submission and are included in the same dataset under the same form structure. Their content is typically narrower — updates to contact information, control affiliates, schedule items, or recertifications — rather than full restatements. Treat the original and amendment together to see current state; treat them separately to distinguish initial registrations from maintenance events. Each amendment must be read against its parent accession to determine what changed.

Form BD (broker-dealer registration)

Form BD is the Section 15(b) registration foundation that SBSE-BD explicitly cross-references and relies on. The two are complementary, not overlapping:

• Channel: Form BD is filed through the FINRA CRD system; SBSE-BD is filed on EDGAR. A researcher working only from EDGAR sees SBSE-BD but not the underlying BD record.
• Content: Form BD carries the full ownership, control, disciplinary, and business-activity disclosures. SBSE-BD adds only the incremental items required for SBS dealing — notably Schedule F for nonresident applicants and the Section 15F certifications.
• Substitutability: Neither stands in for the other. Form BD alone does not establish SBS-entity registration; SBSE-BD alone does not describe the firm's broker-dealer footprint.

Form 7-R (CFTC swap dealer registration)

Form 7-R registers swap dealers and major swap participants with the NFA under the CFTC's parallel Title VII regime. The structural analogy to SBSE-BD ends at the jurisdictional boundary:

• Product scope: Form 7-R covers swaps (rates, FX, broad-based indices, commodities); SBSE-BD covers security-based swaps (single-name CDS, narrow-based index swaps, equity-based swaps).
• Regulator and channel: Form 7-R is filed with the NFA and is not on EDGAR; SBSE-BD is SEC, on EDGAR.

Many large dealers hold both registrations, but the filings, supervising agency, and content do not substitute for one another.

Boundary summary

The SBSE-BD dataset uniquely captures one thin slice: SBS-entity registration applications and amendments filed on EDGAR by firms that are already registered broker-dealers, starting when Section 15F registration opened to this cohort in October 2021. It is not the full SBS-registration universe (split across SBSE, SBSE-A, and SBSE-BD by registrant type), not the underlying broker-dealer record (Form BD, off-EDGAR), not the exit record (SBSE-W), and not the CFTC analog (Form 7-R). What no other dataset reproduces is this incremental EDGAR layer sitting on top of Form BD — Schedule F and the Section 15F certifications — that legally authorizes a broker-dealer to act as an SBS dealer or major SBS participant.

Who Uses This Dataset

The population is small, the certifications are consequential, and a focused set of professionals reads specific slices of each record.

Registration and derivatives compliance staff at SBS-dealing broker-dealers

In-house compliance officers, registration specialists, and regulatory operations staff preparing or amending an SBSE-BD use peer filings as drafting precedent. They study how other applicants answered the Y/N items tied to Rules 15Fb2-1 through 15Fb2-4, how senior officer certifications were worded and signed in formData, and how Schedule F was completed by nonresident applicants. The dataset feeds internal benchmarking before an SBSE-BD/A amendment, audit-trail reconstruction across the firm's own filing history, and onboarding material for new registration analysts. headerData filer identifiers populate internal registration databases maintained alongside CRD/IARD records.

Counterparty credit and OTC risk teams

Credit and OTC risk staff at sell-side and buy-side institutions use the dataset to confirm that a trading counterparty actually carries SBSD or MSBSP registration, to flag amendments that signal changes in legal entity, control, or registration scope, and to map the small universe of dealers that may face them in single-name CDS, equity swaps, and other security-based swaps. They focus on filer name, CIK, formerly-known-as fields in applicantOne, and the Y/N flags that distinguish full SBSD from major participant status. Output drives counterparty onboarding gates, ISDA documentation triage, and exposure-policy approvals.

Buy-side onboarding and KYC analysts

Onboarding and KYC analysts at asset managers, hedge funds, pension plans, and insurance accounts that transact in security-based swaps use the dataset to evidence dealer registration in the counterparty due-diligence file. They pull entity identification from headerData, Schedule F details for nonresident dealers, and senior officer certifications from formData to confirm a registered SBSE-BD plus any SBSE-BD/A amendments. The workflow supports counterparty approval checklists, periodic recertification, and documentation required by internal credit committees and external auditors.

Securities and derivatives lawyers

In-house counsel at broker-dealers and outside counsel advising on SBS registration use the dataset as a precedent corpus. They review how applicants drafted responses to disqualification questions, how nonresident filers completed Schedule F (consent to service of process, opinion of counsel on access to books and records, related undertakings), how associated person disclosures were handled, and how senior officers executed the required certifications. The data supports drafting new applications, advising on amendments triggered by control changes or disclosable events, and arguing market practice during regulatory comment cycles.

Examiners and SRO registration staff

Examination staff at the Commission and at the SRO with broker-dealer jurisdiction use the dataset to maintain a current inventory of SBS-registered broker-dealers and to plan reviews. They diff successive formData snapshots for newly affirmative Y/N flags, updated Schedule F attachments, revised senior officer signatories, and changes in entity identifiers to flag firms whose registration profile has shifted since the prior filing. The dataset supports cross-firm exam scoping, population studies of the SBSD universe, and reconciliation between EDGAR and internal registration systems.

Academic and policy researchers

Researchers studying Title VII implementation, security-based swap market structure, and the cost of dealer registration use the dataset as a primary source. The small universe and October 2021 onward sample window make it tractable for hand-coded studies. They build longitudinal records from headerData filer identifiers and filing dates, count and classify SBSE-BD/A amendments, and code Schedule F use as a proxy for the cross-border footprint of the SBSD population.

Competitive intelligence and reference-data analysts

Strategy teams at financial institutions, market-data vendors, and derivatives consultancies use the dataset to map the SBSD and MSBSP universe, monitor entry and amendment activity that signals new SBS-dealing strategy, and enrich entity reference files with an authoritative SBS registration flag and timestamp. They focus on applicantOne identifiers, registration type, and amendment cadence across the SBSE-BD/A history.

Synthesis

Users cluster around three poles: firms that file or may file the form (compliance, registration, legal); counterparties and regulators that need to know who is registered (credit, onboarding, examiners, SROs); and analysts who study the SBS dealer population (researchers, competitive intelligence). Each reads a specific slice — headerData for identification, applicantOne for entity details, the Y/N flags and certifications in formData for substantive status, and Schedule F for nonresident applicants — to drive registration drafting, counterparty approval, examination planning, or market-structure analysis.

Specific Use Cases

The dataset's small universe, fixed item structure, and clear Y/N flags make it well suited to a handful of specific operational workflows.

Maintaining a current inventory of BD-registered SBS dealers and major participants

Build a longitudinal table keyed on cik and crdNo from headerData/filerInfo and applicantOne, then collapse each filer's chronological sequence of SBSE-BD and SBSE-BD/A accessions to derive current registration state. Record the latest values of isSwapDealer and isSwapParticipant (Items 2A and 2B) to separate full SBSDs from MSBSPs. The output is an authoritative reference table used by counterparty risk, KYC, and market-data systems to confirm a firm's Section 15F(b) status.

Pre-filing precedent search for SBSE-BD/A drafting

Registration analysts preparing an amendment query the corpus for prior filings with the same Y/N answer pattern across isSubjectToRegulator, isDerivativesDealer, and isForeignRegulatory, then read those applicants' describeBusiness narratives (Item 6) and execution blocks for wording precedent. Schedule F language — particularly the consent-to-service-of-process clause and the agent-for-service designation — is reused as drafting input for nonresident filings. The workflow shortens internal review cycles before submitting the amendment.

Counterparty onboarding and ISDA documentation evidence

Buy-side KYC teams pull the latest accession for a prospective dealer, verify fullApplicantName, crdNo, and fileNo (the 026-XXXXX series identifier) against internal counterparty masters, and attach the rendered xslSBSE-BD_X01/primary_doc.xml page plus any Schedule F PDFs to the onboarding file as evidence of registration. The Y/N answer to Item 2A versus 2B drives whether the counterparty can be approved for full SBSD-facing trades or only MSBSP-scope exposure. Output feeds the credit committee approval gate and the periodic recertification cycle.

Diffing successive amendments to detect material registration changes

Examination and compliance-monitoring teams pair each SBSE-BD/A accession with the prior accession for the same cik and compute field-level diffs across applicantOne (contact employee, chief compliance officer, business description), the four Y/N item flags, the execution signatory, and the Schedule F foreign regulator list. Newly affirmative isForeignRegulatory flags or replaced chief compliance officers trigger follow-up review. The diff output drives exam scoping and internal alerts on counterparty registration drift.

Mapping the cross-border footprint of the SBSD population

Filter accessions where isForeignRegulatory = Y and parse Schedule F Section II to extract the itemized list of foreign regulatory bodies with which each applicant is registered. Combine with stateOfIncorporation from metadata.json.entities[] and any Schedule F PDF attachments (foreign-regulator letters, opinion-of-counsel documents) to produce a country-by-dealer matrix. Researchers and policy analysts use this matrix to study the international scope of the Section 15F(b) registrant population and the prevalence of nonresident filings.

Reconciling SBS registrations against Form BD and Form SBSE-W

Because SBSE-BD is layered on top of an existing Form BD record and is exited via Form SBSE-W, internal reference-data teams join crdNo from this dataset to FINRA CRD's Form BD records and to SBSE-W withdrawals to detect mismatches — for example, a CRD-active broker-dealer with no SBSE-BD on file that nonetheless appears in SBS trade reports, or an SBSE-BD filer with a subsequent SBSE-W that internal systems still flag as active. The reconciliation supports data-quality remediation in counterparty masters and registration databases.

Dataset Access

The dataset is organized into monthly ZIP containers covering filings from October 2021 to present. The endpoints below expose dataset metadata, the full archive, and individual monthly container files.

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

Returns dataset-level metadata (name, description, last update timestamp, earliest sample date, total records, total size, covered form types, container format, and file types) along with the full dataset download URL and a list of all monthly ZIP containers. Each container entry includes its key, byte size, record count, last updated timestamp, and direct download URL. This endpoint does not require an API key and can be polled to detect which containers were touched in the most recent refresh, so only changed monthly archives need to be re-downloaded.

Example response:

          1
          {
        

          2
            "datasetId": "1f13365b-9ae0-6a5d-94a3-14ede641faef",
        

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

          4
            "name": "Form SBSE-BD Files Dataset",
        

          5
            "updatedAt": "2026-04-16T08:48:06.809Z",
        

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

          7
            "totalRecords": 49,
        

          8
            "totalSize": 3719351,
        

          9
            "formTypes": ["SBSE-BD", "SBSE-BD/A"],
        

          10
            "containerFormat": "ZIP",
        

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

          12
            "containers": [
        

          13
              {
        

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

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

          16
                "size": 138782,
        

          17
                "records": 2,
        

          18
                "updatedAt": "2026-04-16T08:48:06.809Z"
        

          19
              }
        

          20
            ]
        

          21
          }
        

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

Downloads the complete archive containing every Form SBSE-BD and SBSE-BD/A filing in the dataset. Because the dataset is small, a full download is practical for most workflows. This endpoint requires an API key.

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

Downloads one monthly ZIP container identified by its key value (formatted as YYYY/YYYY-MM.zip) from the index response. Use this when you only need filings from a specific month or want to fetch only the containers updated in the latest refresh. This endpoint requires an API key.

Frequently Asked Questions

What forms does this dataset cover?

The dataset covers Form SBSE-BD (the initial registration application) and Form SBSE-BD/A (amendments to a previously filed application). Both form types share an identical schema and are distributed as first-class records in the same dataset.

What does one record in this dataset represent?

One record is a single EDGAR accession — one Form SBSE-BD or Form SBSE-BD/A submission — materialized as a per-accession folder named after the dashless 18-digit accession identifier. The folder contains a metadata.json envelope, the raw primary_doc.xml form payload, an XSL-rendered HTML view at xslSBSE-BD_X01/primary_doc.xml, and any PDF attachments.

Who is required to file Form SBSE-BD?

Form SBSE-BD is filed by a legal entity that is already registered (or concurrently registering) with the SEC as a broker or dealer under Section 15(b) of the Exchange Act and that is applying to register as a security-based swap dealer (SBSD) or major security-based swap participant (MSBSP) under Section 15F(b). Broker-dealers that are not also seeking SBSD/MSBSP status do not file this form, and SBS applicants without broker-dealer registration file the sibling Form SBSE or Form SBSE-A instead.

What time period does the dataset cover?

The dataset begins on October 1, 2021 — aligned with the SEC's October 6, 2021 compliance date for Section 15F registration of security-based swap entities — and continues to the present. Initial SBSE-BD applications cluster in late 2021, and subsequent activity is dominated by SBSE-BD/A amendments.

What file formats are inside each record?

Each record contains XML (the structured primary_doc.xml form payload and the XSL-rendered HTML view, both with the .xml extension), JSON (the metadata.json submission envelope), and optionally PDF attachments such as Schedule F supporting documentation or foreign-regulator letters. Image files attached to the original EDGAR submission are excluded from the dataset copy. The dataset is distributed as monthly ZIP containers under the form-sbsebd-files/ prefix.

How does this dataset differ from Form BD?

Form BD is the underlying broker-dealer registration filed through the FINRA CRD system; Form SBSE-BD is a separate registration filed on EDGAR that layers SBSD or MSBSP status on top of an existing or pending broker-dealer registration. Form BD carries the full ownership, control, disciplinary, and business-activity disclosures, while SBSE-BD carries only the incremental Section 15F items — notably Schedule F for nonresident applicants and the senior-officer certifications. Form BD filings are not part of this dataset.

How are amendments handled in the dataset?

Each Form SBSE-BD/A is a standalone EDGAR submission with its own accession number; amendments do not supersede or replace the original filing in the dataset. To reconstruct a filer's current registration state, walk the chronological sequence of accessions for that filer (keyed on cik or crdNo) and treat each later SBSE-BD/A as an overlay on the prior state.