Form SBSE-C Files Dataset

The Form SBSE-C Files Dataset is a structured collection of every EDGAR submission of Form SBSE-C, the short certification filing required under Rule 15Fb2-1 of the Securities Exchange Act of 1934 in connection with the registration of security-based swap dealers (SBSDs) and major security-based swap participants (MSBSPs). Each record is one complete SBSE-C accession identified by its 18-digit accession number and bundles the canonical XML payload, an XSL-rendered XHTML view of the certifications, and a provider-curated metadata.json sidecar describing the EDGAR submission. The form is filed by the registrant entity and signed by a senior officer attesting to written compliance policies and procedures and by a chief compliance officer (or designee) attesting to background checks on associated persons effecting security-based swaps. Dataset coverage begins on October 1, 2021, aligned with the November 1, 2021 compliance date for SBSD/MSBSP registration, and continues forward as new accessions are accepted by EDGAR. Records are distributed inside monthly ZIP containers organized by year and YYYY-MM subfolder, with file types limited to XML and JSON.

Dataset APIs

Dataset Files

What This Dataset Contains

The dataset packages every accepted EDGAR submission of Form SBSE-C — a certification-only filing under Rule 15Fb2-1 that accompanies a substantive registration filing on Form SBSE, Form SBSE-A, or Form SBSE-BD. SBSE-C is a companion form: it is never filed alone. Its function is to attach two written certifications to the registration package — a senior officer certification regarding written compliance policies and procedures, and a chief-compliance-officer (or designee) certification regarding background checks on associated persons who effect security-based swaps. The form contains no narrative business disclosure, no financial statements, and no exhibits; the entire substantive content is two statutorily prescribed attestations plus the identifying information needed to bind those attestations to a specific applicant.

The dataset covers the full filer population for the SEC's security-based swap registration regime under Title VII of the Dodd-Frank Act and reflects every SBSE-C accession disseminated by EDGAR from October 2021 forward. Each accession is delivered as a folder named after the 18-digit accession number (with hyphens stripped) inside monthly ZIP containers. Because the form has been filed exclusively as structured XML with an accompanying SEC XSL rendition since inception, every record contains both the machine-readable XML payload and the human-readable XHTML view, paired with a JSON metadata sidecar.

Content Structure of a Single Record

What one record represents

A single record in the form-sbsec-files dataset is one complete EDGAR submission of Form SBSE-C, identified by its 18-digit accession number. The record is delivered as a folder named after that accession (with hyphens stripped) inside a monthly ZIP container organized by year and YYYY-MM subfolder. Each accession folder bundles the artifacts that together fully reconstitute the filing as it was disseminated by EDGAR: a provider-curated metadata.json describing the submission at the filing level, the canonical primary_doc.xml carrying the structured SBSE-C payload, and an XSL-rendered XHTML view of that same payload at xslSBSE-C_X01/primary_doc.xml. Together these layers represent both the human-readable certification document and its underlying machine-readable representation, paired with a metadata sidecar.

Content layers in a single record

A record contains three layers of content, arranged inside the accession folder as follows:

1. Filing-level metadata layer — metadata.json, a single JSON object summarizing the submission, identifying the filer entity, and listing the document renditions that EDGAR assembled for the accession.
2. Structured XML payload layer — primary_doc.xml at the folder root, conforming to the EDGAR http://www.sec.gov/edgar/sbse/sbsecfiler namespace, containing a headerData block (filer credentials and submission flags) and a formData block (the two certifications).
3. Rendered XHTML layer — xslSBSE-C_X01/primary_doc.xml, an XHTML document produced by applying the SEC's SBSE-C_X01 XSL stylesheet to the canonical XML. Despite the .xml extension, this file is a styled HTML rendition with SEC headers, OMB control block, statutory warnings, and tabulated certification fields suitable for direct human reading.

metadata.json

A single JSON object describing the EDGAR submission. The keys carry filing-level facts rather than the certification content itself:

• formType — fixed at "SBSE-C" for every record in this dataset.
• accessionNo — the canonical 18-digit accession number with hyphens, e.g. "0001708828-25-000010".
• filedAt — ISO-8601 timestamp with timezone offset reflecting the EDGAR acceptance time.
• description — short EDGAR description string supplied by the filer at submission time.
• linkToFilingDetails, linkToTxt, linkToHtml, linkToXbrl — URLs back to EDGAR's filing index page, full-submission text file, rendered primary document, and (empty for SBSE-C) XBRL endpoint.
• documentFormatFiles[] — an array describing every rendition EDGAR generated for the accession, with sequence, size, documentUrl, description, and type for each entry. This typically lists the XSL-rendered XML, the raw XML, and the complete .txt submission package.
• entities[] — one filer entity object per submission, with cik, companyName (suffixed (Filer)), fileNo (the SEC-assigned 026- file number used for SBSD/MSBSP applicants), filmNo, act ("34" for the Exchange Act), stateOfIncorporation, fiscalYearEnd formatted MMDD, and type ("SBSE-C").
• seriesAndClassesContractsInformation[] and dataFiles[] — present but empty for SBSE-C, since the form has no fund series/class structure and carries no data exhibits.
• id — an internal identifier assigned by the dataset provider for deduplication and indexing.

primary_doc.xml — the SBSE-C XML payload

The canonical XML document is rooted at <edgarSubmission xmlns="http://www.sec.gov/edgar/sbse/sbsecfiler"> and divides cleanly into two sibling sections.

The headerData block holds submission identity rather than certification substance. Inside it, submissionType is fixed to SBSE-C; filerInfo > filer > filerCredentials contains a 10-digit filerCik and a filerCcc field that is redacted to XXXXXXXX in disseminated copies; and filerInfo > flags carries booleans such as returnCopyFlag and overrideInternetFlag that govern EDGAR submission behavior.

The formData block carries the two certifications as parallel elements, one per attestation prescribed by Rule 15Fb2-1:

• certificationOne — the Senior Officer Certification. Populated fields are applicantName, cerApplicantName (a duplicate field carrying the applicant name as it appears on the certification line), cerDate formatted MM-DD-YYYY, signature, name, and title. The title field captures the senior officer's role at the applicant (for example, CEO).
• certificationTwo — the Chief Compliance Officer Certification (or designee certification). Populated fields mirror certificationOne minus the title element, which is only emitted when a designee signs in lieu of the CCO; for direct CCO signatures the field is omitted because the role is implicit.

The certification text itself is not embedded in the XML payload as free narrative — the XML is a slot-filling instrument, and the prescribed certification language is supplied at rendering time by the XSL stylesheet, which carries the statutory text by virtue of its association with the SBSE-C_X01 form template.

xslSBSE-C_X01/primary_doc.xml — the rendered XHTML

The XSL-rendered file presents the same data as a fully styled, SEC-branded XHTML document and is structured into three visible sections:

• Filer Information — Filer CIK, masked Filer CCC, LIVE/TEST radio indicator, return-copy checkbox state, and any contact-info placeholders carried from the header.
• Certification 1 — opens with the OMB control block and the federal false-statements warning citing 18 U.S.C. 1001 and 15 U.S.C. 78ff(a), followed by the senior-officer instruction paragraph and the verbatim certification language stating that the senior officer has reasonably determined, after due inquiry, that the applicant has developed and implemented written policies and procedures reasonably designed to prevent violation of the federal securities laws and rules thereunder, and that the senior officer has documented the process by which that determination was reached. A populated table follows, carrying Applicant Name, Date, Signature, Name, and Title.
• Certification 2 — the same OMB and statutory-warning header, followed by the CCO/designee instructions and the verbatim CCO certification text covering background checks on associated persons and the absence of statutory disqualification under Sections 3(a)(39)(A) through (F) of the Exchange Act, with a definitional cross-reference to the associated person term in Section 3(a)(70). A signature table mirrors the one in Certification 1.

Included content

A record includes all machine- and human-readable artifacts needed to interpret the SBSE-C submission as filed: the structured XML carrying the two certifications and their signatures, the rendered XHTML view with the prescribed certification language and OMB header, and the metadata sidecar tying the accession to its filer entity, file number, and submission timestamp. The documentFormatFiles[] array in the metadata cross-references each rendition by EDGAR sequence number and original size, so downstream consumers can verify which physical document each piece of content corresponds to in the original submission.

Excluded or separate content

Several categories of content are structurally absent from a record:

• Image files attached to the EDGAR submission are not packaged in the dataset folder.
• The companion registration filing — Form SBSE, SBSE-A, or SBSE-BD — to which the SBSE-C certification is appended is a separate EDGAR accession and is not bundled into the SBSE-C record. It must be retrieved independently if the substantive registration content is required.
• The filerCcc (CIK Confirmation Code) is redacted to XXXXXXXX in disseminated XML, as is standard EDGAR practice.
• seriesAndClassesContractsInformation[] and dataFiles[] are empty arrays at the metadata level because the form has no series/class concept and carries no data exhibits.

Historical and structural notes

The dataset begins in October 2021, which corresponds to the operative period for SBSD/MSBSP registration under Rule 15Fb2-1 — the rule was adopted as part of the Title VII security-based swap framework, and Form SBSE-C took its XML-plus-XSL form from the start of EDGAR ingestion. Because the form is narrowly scoped to two prescribed certifications with fixed required fields, there has been no material evolution of required Items, Parts, or disclosure sections across the dataset's history. Filing volume is intrinsically low: the universe of registered SBSDs and MSBSPs is small, and certifications are filed only at registration and on subsequent triggering events. The form has been filed exclusively as structured XML with an accompanying SEC XSL rendition since inception; there is no ASCII or legacy HTML era to describe for this filing type.

Interpretation notes

Several nuances matter when extracting or interpreting records:

1. Authoritative source. The canonical authoritative content is the XML in primary_doc.xml; the XSL-rendered XHTML is a derived view and contains static template language (instructions, OMB headers, certification text) that is not present in the XML and must not be confused with filer-supplied data.
2. Duplicate applicant slots. The two applicantName fields inside each certification (applicantName and cerApplicantName) typically carry the same value but are structurally distinct slots and may differ in formatting. Consumers reconciling applicant identity should also cross-check against entities[].companyName in the metadata.
3. Date formats differ. cerDate is formatted MM-DD-YYYY, while filedAt in the metadata is ISO-8601 with timezone. The two dates frequently differ because the certification can be signed before the EDGAR acceptance timestamp.
4. Designee vs. CCO signature. Absence of a title element in certificationTwo indicates that the signer is the Chief Compliance Officer in their formal capacity. A populated title in certificationTwo indicates a designee signature under Exchange Act Section 15F(k).
5. File number stability. The fileNo field uses the 026- prefix that the SEC assigns to security-based swap entity registrants and is the most stable identifier for tracking an applicant across multiple SBSE-family filings.
6. XHTML masquerading as XML. Although the xslSBSE-C_X01/primary_doc.xml path uses an .xml extension, the file is XHTML — content type should be determined by inspecting the document, not by extension.

Who Files or Publishes This Dataset, and When

Who files or discloses the record

Each record is a certification package filed with the SEC by an applicant seeking registration as a security-based swap dealer (SBSD) or major security-based swap participant (MSBSP). The filer of record on EDGAR is the applicant entity itself. The certifications inside the form are signed by two individuals at the applicant:

• A senior officer, who certifies that the applicant has implemented written policies and procedures reasonably designed to prevent violations of the federal securities laws.
• The chief compliance officer (CCO) (or a permitted designee), who certifies that background checks have been performed on associated persons effecting security-based swaps and that those persons are not subject to statutory disqualification.

These individuals sign the form, but the legal filer is the registrant entity.

Filing population

The reporting population is narrow and consists of entities subject to the SEC's security-based swap registration regime under Title VII of the Dodd-Frank Act:

• SBSDs — entities that deal, make markets in, or regularly enter into security-based swaps as an ordinary course of business above the de minimis threshold.
• MSBSPs — non-dealer entities holding substantial security-based swap positions, creating substantial counterparty exposure, or operating as highly leveraged financial firms not subject to federal banking capital requirements.

Applicants may be U.S. or non-U.S. firms, banks, broker-dealers, or other financial entities. Non-resident applicants file on the same basis as domestic applicants, though their broader registration package may include additional service-of-process elements.

When the record is created

Form SBSE-C is event-driven, not periodic. It is triggered by the act of seeking SBSD or MSBSP registration and must be submitted alongside one of three companion registration forms:

• Form SBSE — applicant is not also registered as a broker-dealer or with the CFTC as a swap dealer or major swap participant.
• Form SBSE-A — applicant is also registered with the CFTC as a swap dealer or major swap participant.
• Form SBSE-BD — applicant is also registered with the SEC as a broker-dealer.

There is no calendar-based deadline. The certifications must be current as of the registration submission. Amended Form SBSE-C filings arise when the underlying certifications must be refreshed — for example, on a change of senior officer or CCO, material changes to the certified policies and procedures, or correction of prior certification information. Amendments use the same EDGAR pathway.

The form exists under Rule 15Fb2-1 of the Securities Exchange Act of 1934, implementing Section 15F (added by Title VII). The earliest filings in the dataset date from October 2021, aligned with the November 1, 2021 compliance date for SBSD/MSBSP registration. There is no pre-EDGAR analog.

Important distinctions

• Applicant is the filer; certifying individuals are not. The senior officer and CCO sign personally, but the registrant entity is the EDGAR submitter, similar to how Sarbanes-Oxley CEO/CFO certifications attach to issuer filings.
• No standalone use. Form SBSE-C has no effect on its own. Without an accompanying Form SBSE, SBSE-A, or SBSE-BD, the registration package is incomplete.
• CFTC-only swap dealers are out of scope. Firms that deal solely in swaps (not security-based swaps) register with the CFTC and NFA and do not file SBSE-C. Dual registrants file Form SBSE-A as the SEC companion track and still include SBSE-C.
• Broker-dealers are not automatically SBSDs. A broker-dealer below the SBSD de minimis threshold has no SBSE-C obligation. Once it crosses into SBSD or MSBSP status, it files SBSE-C alongside Form SBSE-BD.
• CCO designee signing. A designee with appropriate authority and knowledge may sign the background-check certification; legal weight is unchanged.
• De-registration is separate. Termination of SBSD or MSBSP status is effected through Form SBSE-W, which is not part of this dataset.

How This Dataset Differs From Similar Datasets or Filings

Form SBSE-C is the certification companion to the SBSE-family registration filings under Rule 15Fb2-1. It is not a stand-alone registration; it attaches to a primary SBSE, SBSE-A, or SBSE-BD application. The most useful comparisons are therefore the other SBSE-family forms, plus a small number of adjacent registration regimes that researchers commonly conflate with it.

Form SBSE (non-bank, non-BD SBSD / MSBSP registration)

Primary registration form for entities that are neither broker-dealers nor banks seeking to register as a security-based swap dealer (SBSD) or major security-based swap participant (MSBSP). Captures business, ownership, control persons, disciplinary history, and associated persons.

Difference: SBSE is the substantive registration with extensive schedules and disciplinary disclosures; SBSE-C is a short two-part attestation. SBSE establishes who the registrant is; SBSE-C attests that compliance policies exist and that background checks on associated persons effecting SBS have been completed. SBSE-C has no independent regulatory function without an underlying SBSE, SBSE-A, or SBSE-BD.

Form SBSE-A (bank SBSD / MSBSP registration)

Abbreviated registration for banks (or separately identifiable bank departments), shortened because applicants are already supervised by federal banking regulators.

Difference: SBSE-A varies by filer population (banks); SBSE-C is a fixed, population-agnostic certification. The certification content does not change based on which parent form it accompanies.

Form SBSE-BD (broker-dealer SBSD / MSBSP registration)

Abbreviated registration for entities already registered as broker-dealers, designed as a thin overlay on existing Form BD disclosures.

Difference: SBSE-BD addresses identity and structure and leans on Form BD data; SBSE-C still requires both the senior officer policies-and-procedures certification and the CCO background-check certification regardless of broker-dealer status.

Form SBSE-W (withdrawal from SBSD / MSBSP registration)

Short termination filing used to exit the regime.

Difference: SBSE-W marks exit; SBSE-C accompanies entry or amendment. Opposite ends of the registrant lifecycle, and SBSE-W contains no compliance certifications.

Form BD (broker-dealer registration)

Long-standing broker-dealer registration under Section 15(b), filed via CRD/IARD rather than EDGAR.

Difference: Form BD governs broker-dealer status generally and is unrelated to SBS dealer registration. It contains no senior officer compliance certification or CCO background-check attestation. Different filing system, different scope, no substitution.

CFTC Form 7-R (NFA swap dealer registration)

NFA registration form for swap dealers and major swap participants under CFTC jurisdiction, covering interest-rate, FX, broad-based index, and most commodity swaps.

Difference: Filed with NFA, not the SEC, and covers the parallel non-security-based swaps regime. Different regulator, different filing system, not on EDGAR. Many dealers register under both regimes, but the records are entirely separate.

Form X-17A-5 / FOCUS Reports

Periodic financial and operational reports of broker-dealers; SBSD financial-responsibility rules (18a-1 through 18a-9) borrow from this framework.

Difference: FOCUS is recurring quantitative financial-condition reporting; SBSE-C is a one-time qualitative compliance attestation tied to registration. They answer different questions about overlapping firms.

Boundary summary

SBSE-C is uniquely defined by its role as a certification companion rather than a registration form. It carries only two attestations required by Rule 15Fb2-1: a senior officer certification that written policies and procedures to prevent federal securities law violations are in place, and a CCO certification that background checks have been performed on associated persons effecting security-based swaps. No other dataset contains these attestations, and they cannot be reconstructed from any related form. To form a complete view of an SBSD/MSBSP entry, pair SBSE-C with the underlying SBSE, SBSE-A, or SBSE-BD; add SBSE-W for exits. Form BD and CFTC Form 7-R cover adjacent but distinct regimes under different filing systems, and FOCUS reports cover financial condition rather than compliance certification. None of these substitute for SBSE-C.

Who Uses This Dataset

The record set is small but legally consequential, and its users are a narrow group of derivatives-focused professionals who care about specific fields: filer CIK, applicant legal name, certifying officer title and signature, certification date, and the parent SBSE-family file number.

Derivatives compliance counsel

In-house and outside counsel drafting Rule 15Fb2-1 certifications use the dataset as a precedent library. They reference signing-officer titles, signature blocks, and certification dates from prior filings to confirm their own senior officer and CCO certifications match peer drafting conventions. The output is filing-ready certification text and CCO-readiness memos.

SBS registration project managers

Registration teams inside dealer applicants track SBSE-C filings through the broader SBSE / SBSE-A / SBSE-BD lifecycle. They use accession-to-file-number linkage and certification timestamps to maintain filing logs, manage post-effective amendments, and trigger re-certification on change of control.

Counterparty onboarding and KYC teams

Buy-side onboarding teams at asset managers, hedge funds, pensions, and insurance accounts trading SBS as principal use the dataset to verify that a prospective dealer counterparty has filed the required certifications. Filer CIK, applicant name, certification date, and signing officer details feed counterparty approval memos, ISDA onboarding files, and KYC refresh records.

Regulators and SRO examination staff

Securities regulators and self-regulatory examination staff use the dataset as a population-level reference for SBS dealer registration completeness. The full record supports exam scoping, registration-gap reports, and identification of missing or stale certifications.

Academic researchers on Title VII implementation

Finance, law, and regulatory economics researchers studying Dodd-Frank Title VII rollout use certification dates and registrant identities to analyze adoption timing, dealer-population concentration, and the operational footprint of Rule 15Fb2-1.

SBS market structure analysts

Sell-side strategy desks, derivatives consultancies, and policy research groups maintain rosters of registered SBS dealers and major participants. They join applicant name, CIK, and parent SBSE file numbers against SBSDR trading data to track new entrants, withdrawals, and competitive positioning.

Reference data vendors

Regulatory and reference-data providers building dealer registries and counterparty master files use the dataset as the canonical source for the certification leg of the dealer record. They emit change events when new SBSE-C filings appear and link them to the parent SBSE-family records distributed to buy-side clients.

Internal audit and second-line controls

Internal audit and compliance-testing teams inside dealer applicants pull their own historical SBSE-C entries to test that the certifying senior officer and CCO had documented evidence — background-check logs, policy inventories, control walkthroughs — supporting the attestation. The dataset feeds control workpapers and evidence files retained for examiner review.

Specific Use Cases

Concrete workflows that draw directly on the SBSE-C accession folder, its primary_doc.xml certification fields, and the metadata.json filer entity block.

• Building a registered SBSD/MSBSP counterparty roster. Buy-side onboarding teams iterate through monthly ZIPs, extract entities[].cik, entities[].companyName, and entities[].fileNo (the 026- prefix), and pair them with cerDate from certificationOne and certificationTwo. The output is a counterparty master keyed by file number and refreshed each time a new accession lands, used to gate ISDA onboarding and KYC approvals.

• Tracking CCO and senior officer turnover at registered dealers. For each filer CIK, sort SBSE-C filings by filedAt and diff the name, signature, and title fields across certificationOne and certificationTwo. The presence or absence of a title element in certificationTwo distinguishes a CCO signature from a designee signature under Section 15F(k), feeding governance-change alerts and second-line controls reports.

• Population-level Title VII adoption analytics. Academic and policy researchers aggregate cerDate and filedAt across the full corpus from October 2021 onward, joined to applicant CIK, to chart Rule 15Fb2-1 adoption curves, time-from-rule-effective-to-certification, and dealer-population concentration. Output is event-time datasets feeding regression analyses on Dodd-Frank rollout.

• Linking certifications to their parent SBSE-family registrations. Reference-data vendors use entities[].fileNo and entities[].cik to match each SBSE-C accession back to the underlying SBSE, SBSE-A, or SBSE-BD filing fetched separately from EDGAR. The joined record reconstructs the full registration package for distribution as a unified dealer-registry feed.

• Drafting precedent library for Rule 15Fb2-1 certifications. Compliance counsel preparing a new applicant's certification pull the rendered XHTML at xslSBSE-C_X01/primary_doc.xml to inspect peer signature-block conventions, officer titles used in certificationOne.title, and date formatting in cerDate. The output is filing-ready certification language and a CCO-readiness checklist benchmarked against accepted filings.

• Detecting missing or stale certifications during exams. Regulator and SRO examination staff cross-reference the SBSE-C population against the active SBSD/MSBSP register, flagging registrants without a recent SBSE-C accession or with a cerDate predating a known change-of-control or amendment trigger. Output feeds exam-scoping memos and registration-gap reports.

Dataset Access

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

This endpoint returns metadata describing the Form SBSE-C Files Dataset, including the dataset name, description, last updated timestamp, earliest sample date (2021-10-01), total records, total size, covered form types (SBSE-C), container format (ZIP), and file types (XML, JSON). It also returns the download URL for the full dataset archive and a list of all individual container files with per-container metadata such as size, record count, updated timestamp, and download URL. Poll this endpoint to detect which containers were modified in the most recent refresh and download only the updated containers on a daily basis. This endpoint does not require an API key.

Example response:

          1
          {
        

          2
            "datasetId": "1f13365b-9ae0-6a35-94d4-993d1fd96199",
        

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

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

          5
            "updatedAt": "2026-04-16T08:36:08.499Z",
        

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

          7
            "totalRecords": 110,
        

          8
            "totalSize": 234559,
        

          9
            "formTypes": ["SBSE-C"],
        

          10
            "containerFormat": "ZIP",
        

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

          12
            "containers": [
        

          13
              {
        

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

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

          16
                "size": 13818,
        

          17
                "records": 4,
        

          18
                "updatedAt": "2026-04-16T08:36:08.499Z"
        

          19
              }
        

          20
            ]
        

          21
          }
        

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

Downloads the complete Form SBSE-C dataset as a single ZIP archive containing every container file. This endpoint requires an API key.

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

Downloads one individual monthly container file instead of the full dataset, useful for incremental updates after consulting the index API. This endpoint requires an API key.

Frequently Asked Questions

What form does this dataset cover?

The dataset covers Form SBSE-C, the certification filing required under Rule 15Fb2-1 of the Securities Exchange Act of 1934 in connection with the registration of security-based swap dealers (SBSDs) and major security-based swap participants (MSBSPs). Every record has a formType of "SBSE-C".

What does one record in this dataset represent?

One record is a single complete EDGAR submission of Form SBSE-C, identified by its 18-digit accession number and delivered as a folder containing metadata.json, the canonical primary_doc.xml payload, and the XSL-rendered XHTML view at xslSBSE-C_X01/primary_doc.xml.

Who is required to file this form?

The legal filer is the applicant entity itself — an SBSD or MSBSP seeking registration with the SEC. The form's two certifications are signed by a senior officer and by the chief compliance officer (or a permitted designee), but the registrant entity is the EDGAR submitter.

When is Form SBSE-C filed?

Form SBSE-C is event-driven and is filed alongside a substantive registration on Form SBSE, SBSE-A, or SBSE-BD. It has no calendar deadline; amendments are submitted when certifications must be refreshed, such as on a change of senior officer or CCO or material changes to certified policies and procedures.

What time period does the dataset cover?

The dataset begins on October 1, 2021, aligned with the November 1, 2021 compliance date for SBSD/MSBSP registration under Rule 15Fb2-1, and continues forward as new accessions are accepted by EDGAR.

What file format is the dataset distributed in?

Records are distributed inside monthly ZIP containers organized by year and YYYY-MM subfolder. Inside each accession folder, the file types are XML (the canonical primary_doc.xml and the XSL-rendered XHTML at xslSBSE-C_X01/primary_doc.xml) and JSON (metadata.json).

How does this dataset differ from Form SBSE, SBSE-A, or SBSE-BD?

Form SBSE, SBSE-A, and SBSE-BD are the substantive registration forms that establish who the registrant is and capture business, ownership, control persons, and disciplinary history. SBSE-C is a short two-part certification companion that attests only that written compliance policies and procedures are in place and that background checks on associated persons effecting security-based swaps have been completed; it has no independent regulatory function without one of the parent registration forms.

How does this dataset differ from CFTC Form 7-R?

CFTC Form 7-R is filed with the National Futures Association for swap dealers and major swap participants under CFTC jurisdiction (interest-rate, FX, broad-based index, and most commodity swaps). It is filed outside EDGAR and covers a parallel non-security-based swaps regime under a different regulator, so its records are entirely separate from the SBSE-C dataset.