Form SBSE Files Dataset

The Form SBSE Files Dataset packages every EDGAR submission of Form SBSE (initial application) and Form SBSE/A (amendment) — the SEC's application for registration as a security-based swap dealer (SBSD) or major security-based swap participant (MSBSP) under Section 15F of the Securities Exchange Act of 1934. Each record is one complete EDGAR accession: a folder identified by the 18-digit accession number containing a filing-level JSON descriptor, the canonical structured XML payload (primary_doc.xml), and an EDGAR-rendered XHTML viewer copy of that payload. The filer is always the applicant legal entity itself — a corporation, LLC, partnership, or bank, U.S. or non-U.S. — that is not registered as an SEC broker-dealer and not registered with the CFTC as a swap dealer or major swap participant; the broker-dealer and CFTC-registered subpopulations use the companion Form SBSE-BD and Form SBSE-C variants instead. The dataset is distributed as monthly ZIP containers organized by calendar year, and coverage begins on October 1, 2021, the operational onset of the SBSD/MSBSP registration compliance regime.

Dataset APIs

Dataset Files

What This Dataset Contains

The dataset captures the Section 15F registration record for SBSDs and MSBSPs as it appears on EDGAR. Form SBSE is the standalone application path under Section 15F of the Exchange Act, used by applicants that are not already registered (or registering) as broker-dealers with the SEC and that are not registered with the CFTC as swap dealers or major swap participants. Form SBSE/A is the amendment variant; it shares the entire internal anatomy of Form SBSE and signals that the filing modifies a previously filed registration application, with changed schedules and Disclosure Reporting Pages tagged accordingly.

The substantive content covered by the dataset includes applicant identity and contact information, business profile and registration scope, statutory disqualification questions, ownership and control structure (direct and indirect), books-and-records arrangements, securities and non-securities affiliations, disciplinary and financial disclosure panels, and an execution block. The dataset is shipped as monthly ZIP containers organized by calendar year, and individual filings are delivered as accession-number folders inside those containers. There are no XBRL data files associated with this form — the registration application is captured as structured XML against a dedicated SBSE filer schema rather than as financial reporting tagged in iXBRL. Coverage begins October 1, 2021, after EDGAR's adoption of the SBSE filer XML schema; because the form has only existed in this single structured-XML era, no ASCII or plain-HTML legacy exists to reconcile.

Content Structure of a Single Record

A single record in the Form SBSE Files Dataset is one complete EDGAR submission of either Form SBSE or Form SBSE/A, identified by its 18-digit accession number and packaged as its own folder inside a monthly ZIP container. The folder collects every document EDGAR accepted for that accession — minus image attachments, which are excluded by design — together with a filing-level JSON descriptor. The substantive application data lives in a single structured XML payload named primary_doc.xml; the rest of the folder is either submission-level metadata or a pre-rendered XHTML viewer copy of that same payload.

Container layout of one record

Each ZIP is rooted at a month-named directory, with one child folder per filing keyed by the 18-digit accession number with the dashes from the canonical EDGAR formatting (NNNNNNNNNN-NN-NNNNNN) stripped. Inside an accession folder, the canonical layout is:

• metadata.json — a single JSON object that describes the EDGAR submission as a whole.
• primary_doc.xml — the structured Form SBSE / SBSE/A payload (the record proper).
• xslSBSE_X01/primary_doc.xml — an XHTML viewer rendering of the form, produced by EDGAR's xslSBSE_X01 stylesheet.

Form SBSE filings are predominantly all-XML: there are no separate exhibits to enumerate and image files are deliberately excluded from the dataset. The file types found in the dataset are XML, JSON, HTML, and occasionally PDF, but for typical SBSE / SBSE/A submissions only the XML and JSON appear; HTML is present only as the XSL viewer alias, and PDF attachments are an edge case rather than the norm.

metadata.json — filing-level descriptor

metadata.json is a single JSON object carrying the submission-level header and the EDGAR document manifest. Its fields are:

• formType — "SBSE" for an initial registration application or "SBSE/A" for an amendment.
• accessionNo — the canonical dashed accession number (e.g. "0001983408-25-000007").
• description — EDGAR's human-readable filing description (e.g. "Form SBSE/A - [Amend]").
• filedAt — ISO-8601 timestamp with timezone offset indicating EDGAR acceptance time.
• linkToFilingDetails — URL to the EDGAR-rendered primary document.
• linkToTxt — URL to the full submission text bundle on EDGAR.
• linkToHtml — URL to the EDGAR filing-index HTML page.
• linkToXbrl — XBRL link, empty for SBSE because the form carries no XBRL data.
• id — internal 32-character hexadecimal identifier for the record.
• documentFormatFiles — array of objects describing every document EDGAR catalogued for the submission. Each entry exposes sequence, size (string; EDGAR omits the size for the viewer alias entry, which therefore carries a single-space value), documentUrl, and type. For Form SBSE filings the entries typically cover the XSL viewer alias, the raw primary_doc.xml, and the full .txt submission bundle.
• entities — array of filer objects (one per filer). Each filer carries companyName (suffixed with " (Filer)"), cik, fileNo (Form SBSE filers carry a 026- series file number specific to security-based swap entity registrations), irsNo, stateOfIncorporation, fiscalYearEnd in MMDD form, act ("34" for the Exchange Act), type (mirrors formType), and filmNo.
• dataFiles — array of supplemental data files; empty for SBSE filings.
• seriesAndClassesContractsInformation — mutual-fund-only array; empty for SBSE filings.

The descriptor is sufficient for the filing-level header — form type, filer identity, file number, filed-at timestamp, and EDGAR links — but all applicant-specific application data must be parsed out of primary_doc.xml.

primary_doc.xml — the structured Form SBSE payload

primary_doc.xml is the canonical Form SBSE / SBSE/A submission expressed as EDGAR XML. The root element is <edgarSubmission> with three namespaces declared:

• xmlns="http://www.sec.gov/edgar/sbse/sbsefiler" — main SBSE schema for the form body.
• xmlns:com="http://www.sec.gov/edgar/common" — shared EDGAR types for addresses and person names.
• xmlns:sbse="http://www.sec.gov/edgar/sbse_drp" — the SBSE Disclosure Reporting Page (DRP) extension schema.

Two top-level sections sit immediately under the root: <headerData> and <formData>.

<headerData> — administrative wrapper

<submissionType> mirrors the form-type value in metadata.json. A <filerInfo> subtree contains <filer><filerCredentials> with <filerCik> zero-padded to ten digits and <filerCcc> masked in the released filing as XXXXXXXX. A <flags> element exposes the boolean-string controls <returnCopyFlag> and <overrideInternetFlag>, which govern EDGAR submission handling.

<formData> — the form body

<formData> carries the substantive application content. Its internal structure mirrors the printed Form SBSE: a five-page applicant block, six lettered schedules (A through F), a regulatory Disclosure Reporting Page block, and an execution block. Mandatory subtrees are always present in the XML, even when they carry only the applicantName placeholder, so absence of substantive data must be checked element-by-element rather than by missing parent tags.

<applicant> — applicant data pages one through five

The <applicant> subtree is split into five page elements matching the printed form's pagination.

• <applicantDataPageOne> — Identity and contact information. Fields include fullApplicantName, taxIdentificationNo, applicantCik, a mainAddress and mailingAddress (each using the shared com:street1 / com:street2 / com:city / com:stateOrCountry / com:zipCode address model), businessTelephoneNumber, and two structured person blocks for contactEmployee and chiefComplianceOfficer. Each person block carries a name (com:firstName and com:lastName), title, phone, and email.
• <applicantDataPageTwo> — Business profile and registration scope. The two registration-scope flags isSwapDealer and isSwapParticipant are encoded as Y / N. A repeating swapOptions element enumerates qualifying conditions for the registration category. Further booleans appear: isCommissionDetermine, isSelfDetermine, isUseMathModels, isSubjectToRegulator, isNonResidentEntity. A repeating prudentialRegulators element names prudential regulators where applicable. Free-text descriptionBusiness describes the applicant's business. Structural identity is captured by legalStatus, monthApplicantFiscalEnds, stateOfFormation, countryOfFormation (EDGAR country code, e.g. X1 or Z4), and dateOfFormation in MM-DD-YYYY form. isSucceeding and isHoldFunds close the page.
• <applicantDataPageThree> — Recordkeeping arrangements and the criminal-disclosure flag panel. Recordkeeping flags include isRecordsKept, isOnBehalf, isControlThroughAgreement, isWhollyOrPartiallyFinance, isEngagedInSecurities, and isControlWithBank. A <criminalDisclosure> block carries isConvictedOfFelony, isChargedWithFelony, isConvictedMisdemeanor, and isChargedMisdemeanor.
• <applicantDataPageFour> — Regulatory and civil-judicial disclosure flags. regulatoryActionDisclosure contains roughly seventeen is* Y/N flags spanning false-statement findings, regulatory orders, denials, suspensions, and other adverse regulatory outcomes. civilJudicialActionDisclosure contains four civil-action booleans: isEnjoined, isFoundInViolationOfRegulation, isDismissed, and isNamedInCivilProceeding.
• <applicantDataPageFive> — Financial and ancillary disclosures. A financialDisclosure block carries hasSubjectOfBankruptcy and hasTrusteeAppointed. Four further booleans address prior SEC registration, transaction effecting, non-resident entity business activity, and supervision by a foreign regulator.

Schedules A through F

The schedule elements are direct XML equivalents of the paper Form SBSE schedules. Only schedules applicable to the applicant carry substantive rows; inapplicable schedules still appear in the XML as empty elements containing only the applicantName placeholder so parsers can rely on their presence.

• <scheduleA> — Direct owners and executive officers. Carries an isAnyIndirectOwners Y/N flag plus a repeating <scheduleAInfo> row per direct owner or officer. Each row contains fullLegalName (omitted when the row is an individual identified by CRD number), entityType (a two-letter state code for entities or I for individuals), titleOrStatus, dateTitleOrStatusAcquired in MM/YYYY form, ownershipCode (a single-letter band such as E, C, D, or NA), controlPerson (Y/N), an optional zero-padded crdNo, and optional free-text description that often runs to a multi-sentence biography.
• <scheduleB> — Indirect owners. Repeating <scheduleBInfo> rows carry fullLegalName, interestOwnedEntity (the directly owned entity through which the indirect interest is held), entityType, status (e.g. Owner), dateTitleOrStatusAcquired, ownershipCode, controlPerson, and irsTaxNo.
• <scheduleC> — Amendment-delta schedule. Defined by the schema for SBSE/A submissions to itemize changes to Schedules A and B; absent in initial filings and frequently omitted in SBSE/A filings that express their changes through the per-schedule initialOrAmended markers instead.
• <scheduleD> — Books, records, and business affiliations. Decomposes into three child schedules.
  • <scheduleDOne> carries an initialOrAmended marker (INITIAL or AMENDED) plus a sectionFour element. sectionFour contains repeating recordsKeptDetails.recordsKept rows describing each external recordkeeper (responseType such as Item 11A, firmOrOrganizationName, structured firmAddress, firmEffectiveDate, free-text descriptionArrangement) and repeating onBehalfDetails.onBehalf rows of the same shape with an optional firmCrdNo for entities the applicant keeps records on behalf of.
  • <scheduleDTwo> describes securities and investment-advisory affiliates. An engagedInSecurities element pins the row to a specific form question (e.g. 13A). Each sectionFive row describes one affiliated firm: partnerCorpOrgName, optional partnerCrdNumber, partnerCorpOrgType, structured partnerAddress, effectiveDate, isForeignEntity, optional countryOfDomicile, isSecurityAct, isInvestmentAdvisoryAct, and a free-text descriptionRelationship.
  • <scheduleDThree> records non-securities affiliations and carries its own initialOrAmended marker.
• <scheduleE> — Reserved for control-person disclosures associated with the disciplinary panels; present in the XML even when empty.
• <scheduleF> — Reserved for additional and continuation disclosures; present in the XML even when empty.

<regulatoryDrpInfo> — Disclosure Reporting Pages

DRP entries live in their own namespace (sbse:) and answer the disciplinary questions on pages three through five. Each <sbse:regulatoryDrp> element contains:

• initialOrAmended — INITIAL or AMENDED.
• respondingTo / responseQuestion — the specific form question the DRP answers (e.g. 14E(2)).
• drpFiledFor — a text classifier such as "One or more control affiliate(s)".
• controlAffiliate.controlAffiliateDetails — crdNumber, personType (Firm or Individual), isPersonRegistered, nameOfFirm, isShouldBeRemoved, and isSubmittedToCRD.
• regulatoryDrpDetails — typically empty when the DRP cross-references a disclosure already filed through FINRA's CRD system; populated with the underlying matter when the SBSE filer must report the event directly.

The schema also defines parallel DRP subtypes for criminal, civil-judicial, bankruptcy, and judgment/lien events. They follow the same initialOrAmended / respondingTo / details pattern and appear only when triggered by an affirmative answer to the corresponding disclosure question.

<execution> — signing block

The final element under <formData> is the legal sign-off page. Its fields are executionDate (MM-DD-YYYY), nameOfApplicant, signature (typed name), nameOfPersonSigning, and titleOfPersonSigning. This element corresponds to the execution panel on the paper Form SBSE.

xslSBSE_X01/primary_doc.xml — rendered XHTML viewer

The accession folder also carries an EDGAR-pre-rendered viewer copy of the form under an xslSBSE_X01/ subdirectory. Despite the .xml extension, this file is an XHTML 1.0 Strict document: it begins with an HTML doctype and an <html> element that declares the SBSE filer namespace as a prefix, embeds a large <style> block, and renders the applicant data pages and schedules as labelled HTML sections suitable for browser display. It is the output of EDGAR's xslSBSE_X01 stylesheet applied to the structured primary_doc.xml at the accession root. It contains no data not already present in the canonical XML and is a redundant presentation layer; structured consumers should treat the accession-root primary_doc.xml as the source of truth.

Excluded or separate content

Image files from the original EDGAR submission are excluded from the dataset by design. Form SBSE filings do not produce XBRL instance documents, so no structured financial data files appear; the linkToXbrl field in metadata.json is consequently empty. Separate exhibit attachments are not part of the typical Form SBSE submission shape — the entire form lives inside primary_doc.xml and there is no fan-out into per-exhibit files. Where the dataset's overall file-type set includes PDF and HTML, those types are reserved for edge-case attachments and the XSL viewer alias respectively; they do not represent independent record content. CCC credentials in <filerCcc> are masked in the released XML.

How SBSE and SBSE/A amendments appear

SBSE/A filings share the entire record anatomy with initial SBSE submissions. Amendment status is signalled at three levels:

• metadata.formType carries the literal value "SBSE/A" and metadata.description is suffixed with "[Amend]".
• headerData.submissionType inside primary_doc.xml mirrors "SBSE/A".
• Each schedule that may be amended carries an initialOrAmended marker (visible on <scheduleDOne>, <scheduleDThree>, and on every DRP entry under <regulatoryDrpInfo>). The marker takes the values INITIAL or AMENDED, allowing change detection at the schedule and DRP level without diffing whole documents.

Schedule C, defined by the schema as the amendment-delta page for direct- and indirect-ownership changes, is reserved for amendment use; many SBSE/A filings instead express their changes through per-schedule markers and revised schedule rows.

Interpretation and extraction notes

• Booleans throughout the form are encoded as Y / N strings, not XML schema booleans. Multi-valued enumerations such as swapOptions and prudentialRegulators repeat the inner element rather than packing values into a delimited string.
• Geographic and jurisdictional fields use the EDGAR two-letter code list (e.g. DE, NY, X1, Z4, A6) rather than free text. The same code list is reused inside metadata.entities[].stateOfIncorporation and inside <com:stateOrCountry> address elements, so cross-document joins on these codes are reliable.
• CRD numbers appear with varying zero-padding (typically nine digits) and apply to both firms and individuals. They are the primary cross-reference key into FINRA's IARD/CRD systems and frequently substitute for repeating identifying detail inside Schedule A rows and DRP pointers.
• DRP blocks may carry only a thin cross-reference to a CRD-filed disclosure (controlAffiliate populated, regulatoryDrpDetails empty) when the underlying event is already reported through FINRA; full DRP detail elements populate only when the SBSE applicant must report the matter directly.
• Mandatory subtrees including every lettered schedule always appear in the XML even when they carry no substantive rows. Empty schedules contain just the applicantName element. Downstream parsers should test for the presence of child rows, not for the presence of the schedule element itself.
• The XHTML viewer file at xslSBSE_X01/primary_doc.xml is a rendering, not a separate data source; do not parse it as XML for structured extraction.
• One filing equals one accession-number folder, and the substantive form content lives in a single XML document. There is no exhibit join step in the typical record, and the entities array in metadata.json is the only place where the EDGAR-side filer identity (CIK, 026- file number, IRS number, state of incorporation, fiscal year end) is exposed in canonicalized form alongside the applicant-side identity in <applicantDataPageOne>.

Who Files or Publishes This Dataset, and When

Who files

Each record in the Form SBSE Files Dataset is a Form SBSE or Form SBSE/A submission made on EDGAR by an entity applying for, or maintaining, registration with the SEC under Section 15F of the Securities Exchange Act of 1934 as a security-based swap dealer (SBSD) or major security-based swap participant (MSBSP). The filer is always the applicant legal entity itself (a corporation, LLC, partnership, or bank, U.S. or non-U.S.). Natural persons named on the form — control persons, executive officers, direct or indirect owners, associated persons — are subjects of disclosure on Schedules A through F, not filers.

Form SBSE captures a narrow residual population: SBSDs and MSBSPs that are not registered (and not concurrently registering) as SEC broker-dealers and not registered with the CFTC as swap dealers or major swap participants. Applicants that already sit in one of those regimes use a different form in the same family:

• Form SBSE-BD — applicant is, or is concurrently becoming, an SEC-registered broker-dealer. Acts as an overlay on Form BD.
• Form SBSE-C — applicant is, or is concurrently becoming, a CFTC-registered swap dealer or major swap participant. Leverages existing CFTC/NFA registration.
• Form SBSE — applicant fits neither overlay. This is the standalone path captured here.

Because most security-based swap dealing in the U.S. is conducted by broker-dealer affiliates of large bank holding companies, the SBSE-BD path dominates the broader registrant universe and the Form SBSE filer population is small.

When the record is created

Form SBSE is event-driven, not periodic. There is no quarterly or annual cadence. Three triggers produce records:

1. Initial registration (Form SBSE). Required before the entity may lawfully act as an SBSD or MSBSP. An applicant qualifies for SBSD status by exceeding the de minimis threshold for security-based swap dealing activity, or for MSBSP status by meeting one of the substantial-position, counterparty-exposure, or highly-leveraged tests in Exchange Act Rule 3a67-1.
2. Amendments (Form SBSE/A). Filed promptly when any previously reported information becomes inaccurate or when a new disclosable event occurs — typically changes in control persons, direct or indirect owners, executive officers, statutory disqualification events, or new disciplinary, regulatory, criminal, or civil-judicial matters. Each amendment is a separate accession; amendments supplement rather than restate the prior filing, and an initialOrAmended marker inside the affected schedules and DRPs flags which sections changed.
3. Successor / reorganization amendments. Material restructurings, successor registrations, and similar corporate events can produce SBSE/A records.

Filings on EDGAR began on October 1, 2021, the operational onset of the SBSD/MSBSP registration compliance regime. Earlier records do not exist.

Regulatory framework

The registration obligation comes from Section 15F of the Exchange Act, added by Title VII of the Dodd-Frank Act (2010), which assigned SBSDs and MSBSPs to SEC jurisdiction (paralleling CFTC jurisdiction over swap dealers and major swap participants). The SBSE form family and final SBSD/MSBSP registration rules were adopted in 2015 (Exchange Act Release No. 34-75611), with the compliance date phased in through 2021.

The form's content tracks established broker-dealer practice: statutory disqualification questions mirror those on Form BD and invoke the disqualification standards in Section 3(a)(39); schedules collect direct owners (A), indirect owners (B), control persons and disciplinary affiliates (C–F); and Disclosure Reporting Pages (DRPs) capture regulatory, criminal, civil-judicial, bankruptcy, and judgment/lien matters. CRD numbers are carried through for firms and individuals already in FINRA's CRD system, but Form SBSE is filed directly with the SEC through EDGAR — not through CRD. FINRA does not act as registration intake for SBSE applicants, because by definition they are not broker-dealers.

Important distinctions

• Form scope. The dataset contains only Form SBSE and Form SBSE/A. It does not include Form SBSE-BD, SBSE-BD/A, Form SBSE-C, SBSE-C/A, or Form SBSE-W (withdrawal). A complete view of all SBSD/MSBSP registrants requires combining this dataset with those companion filings.
• Deregistration is not an SBSE/A event. An entity exiting SBSD/MSBSP status files Form SBSE-W, which is outside this dataset.
• Filed, not furnished. SBSE and SBSE/A are filed and form part of the official Commission registration record for the applicant.
• Separate from operational reporting. Form SBSE does not satisfy or displace Regulation SBSR transaction reporting, the Rule 18a-5 through 18a-9 recordkeeping regime, or the Rule 18a-1 / 18a-3 capital and margin rules. Those obligations run independently once the entity is registered.

How This Dataset Differs From Similar Datasets or Filings

Form SBSE sits in a narrow corner of SEC registration: the Section 15F entry-point application for SBSDs and MSBSPs. The most useful comparisons are with the other forms in the SBSE family, with the broker-dealer and investment adviser registration regimes it structurally resembles, and with the periodic financial reports that the same firms file later in their lifecycle.

Form SBSE-BD

The parallel SBSD/MSBSP application for entities already registered, or concurrently registering, as SEC broker-dealers. Same statutory purpose as Form SBSE, but shorter: most identifying and disciplinary detail is already on file via Form BD, so SBSE-BD piggybacks on that record. The filer populations do not overlap. Form SBSE covers applicants that are neither broker-dealers nor CFTC-registered swap dealers; SBSE-BD covers the broker-dealer subset.

Form SBSE-C

The third variant in the family, used by entities already registered with the CFTC as swap dealers or major swap participants. Streamlined like SBSE-BD because it leans on CFTC/NFA records. Form SBSE carries the deepest disclosure load of the three precisely because no parallel registration exists to rely on. SBSE and SBSE-C cover non-overlapping subpopulations distinguished by CFTC status.

Form SBSE-W

The withdrawal form for deregistering as an SBSD or MSBSP. Lifecycle counterpart to the three application variants: SBSE-W records exits, while SBSE records entries and amendments. Much shorter in content, focused on termination representations rather than applicant disclosure. Complementary to SBSE for building a full registration timeline, but not a substitute.

Form BD

The broker-dealer registration form, filed through FINRA's CRD system rather than EDGAR. SBSE was deliberately modeled on Form BD (disqualification questions, control-affiliate schedules, principal officer disclosure), but the regimes differ: Form BD registers Section 15 broker-dealers, Form SBSE registers Section 15F swap intermediaries. Form BD is not in EDGAR and is not part of this dataset. For pure-play SBSDs captured here, no Form BD analog exists because the filer is, by definition, not a broker-dealer.

Form ADV

The investment adviser registration form, filed through IARD. Surface resemblance to SBSE in that both are entity-level SEC applications with schedules covering ownership, control, disciplinary history, and business activities. Substantively different: ADV registers advisory businesses under the Investment Advisers Act, with disclosure of services, fees, custody, and clients; SBSE registers swap intermediaries under the Exchange Act, with SBSD-specific Schedules. Populations intersect only in dual-registrant cases, and the forms remain non-substitutable. Form ADV is also not housed in EDGAR-based datasets.

Form X-17A-5 / FOCUS reports

A periodic financial reporting regime, not a registration regime. SBSE captures one-time application and amendment events; Form X-17A-5 captures the ongoing financial condition of the same firms, including net capital, segregation, and audited annual financials. SBSE is narrative and schedule-based; X-17A-5 is recurring, tabular, and numeric. SBSE defines the population; X-17A-5 measures it. FOCUS reports are filed by broker-dealers on this same X-17A-5 chassis.

Boundary summary

Form SBSE is distinct as the full-scope, standalone application for SBSDs and MSBSPs that have no parallel SEC broker-dealer registration and no CFTC swap dealer registration. That makes it the most disclosure-heavy of the three SBSE variants and the cleanest view of a pure-play security-based swap intermediary at registration. SBSE-BD and SBSE-C cover adjacent, non-overlapping filer subpopulations within the same Section 15F regime; SBSE-W covers the deregistration end of the lifecycle; Form BD and Form ADV are structurally analogous applications for different regimes and live outside EDGAR; FOCUS and X-17A-5 cover post-registration financial condition. Together these record types span the full SBSD lifecycle; individually, each occupies a clearly bounded slice that the others do not replicate.

Who Uses This Dataset

Form SBSE and SBSE/A filings define the registered population of SBSDs and MSBSPs under Section 15F. The dataset serves a narrow set of professionals who each anchor on different parts of the record: applicant identifying pages, Schedules A through F, the disclosure reporting pages (DRPs), control-relationship schedules, and certifications.

Registration counsel and compliance officers at applicants

In-house compliance staff and outside securities counsel preparing Form SBSE or SBSE/A filings benchmark drafting against peer submissions. They study how others structure Schedule A direct-owner disclosures, Schedule B indirect-ownership chains, Schedule D other-business descriptions, Schedule E control persons, and Schedule F associations with statutorily disqualified persons, and how peers calibrate DRP entries for criminal, regulatory, civil judicial, and financial events. Output: draft filings, amendment triggers, and disclosure remediation.

Counterparty onboarding and credit teams

Onboarding, credit, and legal-negotiation desks at buy-side managers, dealers, and insurance accounts use the dataset to confirm SBSD or MSBSP status before trading. They pull the applicant identifying pages for legal entity identifiers, Schedules A and B to roll exposures up to ultimate parents, Schedule E to flag related-party and wrong-way risk, and the DRP block to trigger enhanced due diligence. Output: counterparty approval memos and ISDA or SBS protocol negotiations.

KYC and financial-crime analysts

KYC and AML teams at banks, prime brokers, and clearing intermediaries use the filings as primary-source confirmation of ownership and disciplinary facts. Schedules A and B feed beneficial-ownership trees, Schedule E identifies natural-person controllers, and DRPs feed sanctions, PEP, and adverse-media screening. Output: KYC files, periodic refresh records, and EDD escalations when SBSE/A amendments change the picture.

Reference-data and dealer-list maintainers

Legal-entity master and regulatory-list teams at trading venues, central counterparties, data vendors, and large dealers reconcile internal SBSD and MSBSP lists against EDGAR. They consume accession metadata, applicant identifying pages, and the SBSE-versus-SBSE/A status flag. Output: counterparty taxonomy updates and eligibility flags feeding clearing, trading, and risk systems.

Counterparty credit risk and exposure aggregation

Risk teams at large financial institutions map registered SBS entities into group hierarchies. Schedules A, B, and E drive parent attribution for single-counterparty credit limits, large-exposure reporting, and stress testing. Output: limit setting, netting decisions, and group-level exposure reporting.

Regulators, examiners, and policy staff

Registration, examination, and policy teams working on the Title VII regime use the dataset as a population view of who has entered the SBSD and MSBSP regime since October 2021. They focus on counts of original versus amended filings, DRP-event distribution, Schedule A and B ownership structures, and statutory disqualification responses. Output: rulemaking impact analysis, examination scoping, and registrant statistics.

Securities and derivatives lawyers

Outside counsel advising applicants and registrants use the dataset to benchmark Schedule D business descriptions, Schedule E control disclosures, and DRP drafting against peers, and to advise on amendment obligations when ownership, control, or disciplinary facts change. Output: registration drafts, amendment strategy, and responses to staff comments.

Regulatory affairs at SBSDs and MSBSPs

Policy teams at registered firms track the peer population: how others characterize swap-dealing activity in Schedule D, how amendments capture corporate restructurings via Schedules A, B, and E, and how chief compliance officer and associated-person attestations are framed on the certifications page. Output: internal regulatory mapping and trade-association input on Section 15F implementation.

Academic researchers

Researchers in financial economics and securities regulation use the dataset to study buildout of the post-Title VII SBS regime. They analyze filing dates, original-to-amendment ratios, ownership-chain structure across Schedules A, B, and E, DRP-event prevalence, and disqualification responses. Output: working papers on regulatory implementation and comparative studies against the CFTC swap dealer regime.

Derivatives reporters and trade-press analysts

Journalists covering derivatives and post-Dodd-Frank market regulation use the filings to identify newly registered SBSDs and MSBSPs, trace cross-border dealer-group ownership through Schedules A, B, and E, and surface DRP disclosures. Output: registration-trend coverage and investigative pieces on specific applicants.

Specific Use Cases

The following workflows tie specific record components to the analytical or operational tasks they support.

Building and refreshing an SBSD/MSBSP counterparty whitelist

Reference-data teams reconcile internal dealer lists against the registered population by iterating monthly ZIPs, reading metadata.formType to separate SBSE from SBSE/A, and pulling entities[].companyName, cik, and the 026- series fileNo for every accession. Combined with applicantDataPageOne fields (fullApplicantName, taxIdentificationNo, mainAddress) and the applicantDataPageTwo isSwapDealer / isSwapParticipant flags, this produces a counterparty taxonomy update with a clear registration-status flag fed into clearing, trading, and risk systems.

Beneficial-ownership trees for KYC and single-counterparty credit limits

KYC analysts and credit-risk teams parse <scheduleA> rows for direct owners (capturing fullLegalName, entityType, ownershipCode, controlPerson, and crdNo) and chain them through <scheduleB> interestOwnedEntity links to reach indirect parents. The resulting tree drives beneficial-ownership files, group attribution for large-exposure reporting, and natural-person controller identification for sanctions and PEP screening.

Disciplinary-event screening from the DRP block

Onboarding, EDD, and adverse-media teams iterate <regulatoryDrpInfo> entries plus the parallel criminal, civil-judicial, bankruptcy, and judgment/lien DRP subtypes to extract respondingTo, drpFiledFor, and controlAffiliate.controlAffiliateDetails (crdNumber, personType, nameOfFirm). DRPs with populated regulatoryDrpDetails are routed for direct review; thin CRD cross-references trigger an IARD/CRD lookup. Output: EDD memos, escalation tickets, and refresh records keyed off SBSE/A amendments that add or amend DRPs.

Amendment-delta detection without document diffing

Compliance teams and examiners detect what changed in an SBSE/A filing by reading the initialOrAmended markers on <scheduleDOne>, <scheduleDThree>, and every <sbse:regulatoryDrp> entry, cross-checked against metadata.formType == "SBSE/A" and the [Amend] suffix on metadata.description. This isolates amendment scope (ownership change, recordkeeper change, new disciplinary event) without diffing whole XML payloads and feeds amendment-trigger review and examination scoping.

Peer-benchmarking application drafts

Registration counsel and in-house compliance staff preparing a new Form SBSE or SBSE/A benchmark drafting by extracting the descriptionBusiness free-text from <applicantDataPageTwo>, the descriptionArrangement text in <scheduleDOne> recordkeeper rows, the descriptionRelationship text in <scheduleDTwo> affiliate rows, and the Schedule A description biographies. Filtering peers by swapOptions, prudentialRegulators, and legalStatus produces a comparable corpus for calibrating disclosure tone, DRP framing, and Schedule D narrative depth.

Recordkeeper and affiliate-network mapping

Reference-data and supervisory teams build a directed graph of external recordkeepers and affiliated securities firms by harvesting <scheduleDOne> recordsKeptDetails.recordsKept rows (firmOrOrganizationName, firmAddress, firmEffectiveDate) and <scheduleDTwo> sectionFive rows (partnerCorpOrgName, partnerCrdNumber, isForeignEntity, countryOfDomicile, isSecurityAct, isInvestmentAdvisoryAct). The output is a service-provider concentration view and a cross-registrant affiliate map useful for systemic-risk and conflict-of-interest analysis.

Population statistics for the Section 15F regime

Researchers and policy staff use metadata.filedAt, metadata.formType, and entities[].stateOfIncorporation across the full dataset (October 2021 onward) to compute registration cohorts, initial-to-amendment ratios, jurisdictional distribution, and DRP-event prevalence rolled up from <regulatoryDrpInfo>. Combined with the applicantDataPageThree and applicantDataPageFour Y/N disclosure flags, this supports rulemaking impact analysis and comparative studies against the CFTC swap dealer regime.

Dataset Access

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

Returns dataset metadata and the list of all available container files. The response includes the dataset name, description, last updated timestamp, earliest sample date (2021-10-01), total records, total size, covered form types (SBSE, SBSE/A), container format (ZIP), file types (XML, PDF, JSON, HTML), the full dataset download URL, and per-container metadata such as size, record count, updated timestamp, and download URL. Use this endpoint to monitor which monthly containers have changed in the most recent refresh and to selectively download only updated containers on a daily basis. This endpoint does not require an API key.

Example response:

          1
          {
        

          2
            "datasetId": "1f13365b-9ae0-6a33-8a56-c9d56fce7f33",
        

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

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

          5
            "updatedAt": "2026-04-16T08:35:30.076Z",
        

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

          7
            "totalRecords": 290,
        

          8
            "totalSize": 115150705,
        

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

          10
            "containerFormat": "ZIP",
        

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

          12
            "containers": [
        

          13
              {
        

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

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

          16
                "size": 13818783,
        

          17
                "records": 12,
        

          18
                "updatedAt": "2026-04-16T08:35:30.076Z"
        

          19
              }
        

          20
            ]
        

          21
          }
        

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

Downloads the complete dataset as a single ZIP archive containing all monthly containers from the earliest sample date to the latest refresh. This endpoint requires an API key.

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

Downloads one monthly container ZIP as listed in the dataset index, which is useful for incremental syncing or backfilling a specific month. This endpoint requires an API key.

Frequently Asked Questions

What forms does this dataset cover?

The dataset contains only Form SBSE (initial application) and Form SBSE/A (amendment), the Section 15F registration application for security-based swap dealers and major security-based swap participants. It does not include Form SBSE-BD, Form SBSE-C, or Form SBSE-W; a complete view of all SBSD/MSBSP registrants requires combining this dataset with those companion filings.

What does one record in this dataset represent?

One record is one complete EDGAR submission of Form SBSE or Form SBSE/A, identified by its 18-digit accession number and packaged as its own folder containing metadata.json, the structured primary_doc.xml payload, and an xslSBSE_X01/primary_doc.xml XHTML viewer copy. Image files from the original EDGAR submission are excluded by design.

Who is required to file Form SBSE?

The applicant legal entity itself — a corporation, LLC, partnership, or bank, U.S. or non-U.S. — files Form SBSE before it may lawfully act as an SBSD or MSBSP. Only applicants that are not SEC-registered broker-dealers and not CFTC-registered swap dealers or major swap participants use this form; the broker-dealer and CFTC-registered subpopulations file Form SBSE-BD or Form SBSE-C instead.

When are records added to the dataset?

Form SBSE is event-driven rather than periodic. New records appear when an entity files an initial registration application, when a previously reported fact becomes inaccurate and triggers an SBSE/A amendment, or when corporate events such as successor registrations or material restructurings produce an amendment.

What time period does the dataset cover?

The dataset begins on October 1, 2021, the operational onset of the SBSD/MSBSP registration compliance regime and the date EDGAR began accepting Form SBSE filings under the dedicated SBSE filer XML schema. Earlier records do not exist, and the schema namespaces and page-and-schedule element structure described above apply uniformly across the entire dataset.

What file format is the dataset distributed in?

The dataset is distributed as monthly ZIP containers organized by calendar year, with one child folder per accession inside each container. File types found across the dataset are XML, JSON, HTML, and occasionally PDF; for typical SBSE / SBSE/A submissions only the XML payload and JSON descriptor appear, with HTML present only as the EDGAR XSL viewer rendering.

How does this dataset differ from Form SBSE-BD and Form SBSE-C datasets?

All three forms register entities under Section 15F, but they cover non-overlapping subpopulations. Form SBSE-BD is used by applicants that are or are concurrently becoming SEC-registered broker-dealers and piggybacks on Form BD; Form SBSE-C is used by applicants already registered with the CFTC as swap dealers or major swap participants and leans on CFTC/NFA records; Form SBSE — the form covered by this dataset — is the standalone full-disclosure application for pure-play SBSDs and MSBSPs that have neither parallel registration.

Are XBRL data files included?

No. Form SBSE filings do not produce XBRL instance documents, so no structured financial data files appear in the dataset; the linkToXbrl field in metadata.json is consequently empty. The registration application is captured as structured XML against a dedicated SBSE filer schema rather than as financial reporting tagged in iXBRL.