Form SBSE-A Files Dataset

The Form SBSE-A Files Dataset is the EDGAR-native collection of short-form SEC registration applications submitted by security-based swap dealers (SBSDs) and major security-based swap participants (MSBSPs) that are also registered with the Commodity Futures Trading Commission (CFTC) as swap dealers or major swap participants. Each record represents one Form SBSE-A initial application or one Form SBSE-A/A amendment as filed on EDGAR, bundled together with its structured XML payload, an HTML rendering, the SEC-API metadata header, and the filer-supplied PDF exhibits (including the NFA Form 7-R packet on which the short-form path relies). Filers are the applicant entities themselves — large global derivatives dealers, swap-dealing affiliates of bank holding companies, broker-dealer affiliates active in equity and credit derivatives, and non-U.S. dealing entities transacting with U.S. counterparties. The dataset begins on October 1, 2021, the opening of EDGAR's submission window in the run-up to the November 1, 2021 SBSD/MSBSP compliance date, and is updated continuously as new applications and amendments are filed. Containers are distributed as ZIP archives containing XML, PDF, JSON, and HTML files.

Dataset APIs

Dataset Files

What This Dataset Contains

The dataset captures every Form SBSE-A and Form SBSE-A/A filing submitted to EDGAR from October 2021 onward. Form SBSE-A is the short-form application for registration with the SEC as a security-based swap dealer or major security-based swap participant, available under Rule 15Fb2-1 of the Securities Exchange Act of 1934 to entities already registered with the CFTC as a swap dealer or major swap participant. Rather than re-document the full operational, organizational, and disciplinary disclosures collected on the long-form Form SBSE, Form SBSE-A piggybacks on materials already on file with the CFTC and the National Futures Association (NFA) — principally NFA Form 7-R and its supporting documents — and supplements them with a compact set of SEC-specific certifications, schedules, and identifying disclosures. Form SBSE-A/A is the amendment vehicle used to update previously submitted information, frequently to refresh the principals roster (Schedule A), to revise third-party-arrangement disclosures (Schedule B), or to refile certifications.

The dataset covers the full population of CFTC-registered SBSD/MSBSP applicants that have used the short-form path. Both U.S. and non-U.S. entities appear, reflecting the heavy presence of foreign bank entities among SBSD registrants. Records are packaged as ZIP containers; inside each container, the file types are XML (the structured form payload), PDF (filer exhibits), JSON (the SEC-API metadata header), and HTML (the EDGAR XSL rendering). Form SBSE-A was created by SEC rulemaking that took effect for security-based swap dealer registration in 2021, and EDGAR has accepted the form from October 2021 onward, so every record from the dataset's start date forward follows the same XML namespace, element vocabulary, and packaging convention; there is no legacy ASCII or pre-XML era for this form type.

Content Structure of a Single Record

What one record represents

One record corresponds to a single Form SBSE-A or Form SBSE-A/A submission as it was filed on EDGAR, identified by its 18-digit accession number. A record is not a single file but the bundle of artifacts that together constitute the EDGAR submission: the structured XML form, an HTML rendering of that form, the SEC-API metadata header, and the filer-supplied PDF exhibits. All files belonging to one accession are grouped into a folder named after that accession (no dashes), and that folder is the atomic record unit. A record is either an initial registration (SBSE-A) or an amendment to a previously submitted registration (SBSE-A/A); the two share the same internal anatomy and differ mainly in the submissionType flag and in the typical presence of a "summary of changes" exhibit on amendments.

Top-level layout of a record

Every record folder contains four classes of artifact:

1. metadata.json — the SEC-API-generated submission header summarizing the filing, the filer's entity attributes, and the inventory of attached documents.
2. primary_doc.xml — the canonical structured EDGAR submission, in the SBSE-A XML namespace, carrying the entire form payload.
3. xslSBSE-A_X01/primary_doc.xml — an XHTML 1.0 Strict, CSS-styled HTML rendering of the same form, produced by the EDGAR XSL stylesheet for human viewing. The .xml extension is misleading; the body is HTML.
4. One or more PDF exhibits — filer-supplied unstructured documents whose roles are identified by EDGAR exhibit-type codes referenced in metadata.json.

The complete EDGAR submission .txt wrapper that EDGAR assembles around all these pieces is referenced by URL inside metadata.json but is not redistributed inside the record folder. Image files (logos, scanned signature graphics, and similar binary illustrations) are excluded from the record folder; otherwise the substantive submission content is preserved in full.

metadata.json — submission header and inventory

metadata.json is a flat JSON object that exposes all the EDGAR-level facts needed to identify, locate, and inventory the filing without parsing the XML body. Its salient fields fall into four groups.

Submission identity. formType (SBSE-A or SBSE-A/A); accessionNo in dashed form (e.g. 0001062577-25-000009); a human-readable description (e.g. Form SBSE-A/A - [Amend]); and filedAt as an ISO-8601 timestamp with timezone offset.

Canonical EDGAR links. linkToFilingDetails, linkToHtml, linkToTxt, and linkToXbrl point back to the public EDGAR endpoints for the filing.

Document inventory. documentFormatFiles[] enumerates every file that was part of the original EDGAR submission. Each entry carries a sequence number, a byte size (occasionally blank), a documentUrl, an exhibit type code, and an optional human description. The type field is the load-bearing identifier mapping each file to its regulatory role — SBSE-A or SBSE-A/A for the structured form itself and the EX-99.x family for attached exhibits. A trailing entry with blank sequence and type and the description "Complete submission text file" represents the master .txt wrapper; this file is not included in the record folder but is locatable via its URL. The exhibit type codes used by this form are EX-99.32 APP CRT DOC (applicant certification), EX-99.34 OPIN COUNSL (opinion of counsel), EX-99.35 OTHER (other supporting material such as summary-of-changes memos), and EX-99.36 FORM 7-R (the NFA Form 7-R registration packet on which the short-form application relies).

Entity block. entities[] carries one element per filer/subject. Per-entity fields include companyName (with a (Filer) role suffix), cik, irsNo, fileNo (the SEC-assigned SBS file number, typically of the form 026-xxxxx), filmNo, act (34 for Exchange Act filings), type (echoes formType), fiscalYearEnd as MMDD, stateOfIncorporation using EDGAR's state/country code vocabulary (including non-US codes such as X0 and 2M), sic (SIC code with description, when present), and tickers[] listing equity tickers for publicly traded filers (e.g. BNS, TD). The arrays seriesAndClassesContractsInformation[] and dataFiles[] are part of the schema but are empty for this form type.

A SEC-API-internal 32-hex id is also provided for record-level addressing.

primary_doc.xml — structured form payload

primary_doc.xml is the authoritative carrier of the form's content. The root element is <edgarSubmission> in the namespace http://www.sec.gov/edgar/sbse/sbseafiler, with shared types drawn from http://www.sec.gov/edgar/common. The root has exactly two children: <headerData> and <formData>.

headerData

EDGAR-level submission control information. submissionType repeats the form code (SBSE-A or SBSE-A/A). filerInfo.filer.filerCredentials carries the filerCik and a filerCcc field that is redacted in published filings (XXXXXXXX). filerInfo.flags holds the boolean toggles returnCopyFlag and overrideInternetFlag that EDGAR uses for submission processing.

formData.applicant

The applicant block is divided into three numbered sub-blocks corresponding to logical groupings of items on the form.

applicantOne carries identity and contacts. Identifiers: applicantNFANumber, fullApplicantName, irsEmplIdentNo, applicantNFAId, applicantCik, and an optional applicantUic (the firm's LEI). Address fields are structured under mainAddress and an optional mailingAddress, both using the com:street1, com:street2, com:city, com:stateOrCountry, and com:zipCode shared types. Communications fields include businessTelephoneNumber and an optional websiteUrl. Two structured personnel blocks — contactEmployee and chiefComplianceOfficer — each carry a name, title, phone, and emailAddress.

applicantTwo captures the applicant's business profile via a battery of yes/no flags — isSwapDealer, isSwapParticipant, isCommissionDetermine, isSelfDetermine, isMathematicalModels, isNonResidentEntity, isSubjectToRegulator, isInvestmentAdvisor, isRegisteredAsOther, isEngageInOtherBusiness, isHoldFunds — alongside narrative fields: registeredAs (the CFTC registration capacity, e.g. Swap Dealer), descriptionBusiness (free text describing the business), foreignFinancialRegulatory (a semicolon-separated list of foreign regulators), and an optional description3C block describing substituted-compliance program elements where applicable.

applicantThree gates the inclusion of subsequent schedules with a parallel set of flags — isRecordsKept, isOnBehalf, isControlThroughAgreement, isWhollyOrPartiallyFinance, isSucceeding, isForeignRegulatory, isNotIdentified — plus a numberOfPrincipals count that anchors Schedule A's expected size.

formData.scheduleA

Schedule A is the principals/officers roster. It contains one <scheduleAInfo> element per principal, each capturing a structured individualName (com:firstName, com:middleName, com:lastName), a free-text titleOrStatus describing the role, dateTitleOrStatusAcquired and dateBeganWorking as MM/YYYY strings, an haveOwnershipInterest Y/N flag, an nfaIdentificationNo, and an optional crdNo for FINRA-registered individuals.

formData.scheduleB

Schedule B documents third-party arrangements that bear on the applicant's records, operations, control, and financing. It is organized as two sections.

sectionOne is a narrative prose description of the applicant's business; some filings also carry uicNumber and assigningRegulators fields here.

sectionTwo is structured into four parallel arrangement arrays, each populated only if the corresponding flag in applicantThree is true. All four share a common entry shape: a responseType tying the entry back to a numbered Item on the form (Item 13A, Item 13B, Item 14, or Item 15); a firmOrOrganizationName; optional firm identifiers (firmCrdNo, firmNfa, firmSecFileNumber, firmCikNumber, firmUic); a structured firmAddress; a firmEffectiveDate in MM-DD-YYYY; and a free-text descriptionArrangement. The four arrays are:

• recordsKeptDetails.recordsKept[] (Item 13A) — third parties holding the firm's books and records.
• onBehalfDetails.onBehalf[] (Item 13B) — parties acting on the applicant's behalf, including trading venues, custodians, and clearing brokers.
• controlThroughAgreementDetails.controlThroughAgreement[] (Item 14) — parents and affiliates exerting control through agreement.
• whollyOrPartiallyFinanceDetails.whollyOrPartiallyFinance[] (Item 15) — affiliates wholly or partially financing the applicant.

formData.scheduleF

Schedule F is a minimal closing block carrying a name and an applicantNFANo, used to re-anchor the schedule package to the applicant.

formData.execution

The execution block is the form's signature segment. It carries date (MM-DD-YYYY), nameOfApplicant, signature (the typed signature string), nameOfPersonSigning, and titleOfPersonSigning.

xslSBSE-A_X01/primary_doc.xml — rendered view

This companion file is the SEC viewer's XSL-stylesheet rendering of primary_doc.xml into XHTML 1.0 Strict, with embedded CSS classes (pageHeader, title1, warning, etc.) that mirror EDGAR's print/preview layout. It introduces no information beyond what is already encoded in primary_doc.xml; it exists solely to support human display and should not be parsed as an independent source.

PDF exhibits

PDFs are unstructured, filer-supplied attachments. Filenames follow no convention — examples include Form7Rcomplete.pdf, BooksandRecordsOpinion.pdf, MemoSep2025.pdf, and summaryofchange.pdf — so role identification depends on cross-referencing the type attribute in metadata.json::documentFormatFiles[]. The recurring exhibit roles for this form are:

• EX-99.32 (APP CRT DOC) — applicant certification documents: signed attestations regarding regulatory compliance and the accuracy of the submission.
• EX-99.34 (OPIN COUNSL) — opinion of counsel addressing books-and-records arrangements, registration capacity, or other legal matters required by the form's instructions.
• EX-99.35 (OTHER) — catch-all for supporting material; on amendments this is most often a human-readable summary of changes against the prior version of the application.
• EX-99.36 (FORM 7-R) — the NFA Form 7-R registration packet (often a complete copy and, on amendments, an additional update PDF). This is the central piggybacked document that allows the SEC short-form pathway under Rule 15Fb2-1 to substitute for the long-form SBSE disclosures already collected by the CFTC and NFA.

What the dataset includes and excludes

Each record includes metadata.json, the structured primary_doc.xml, the XSL-rendered HTML companion under xslSBSE-A_X01/, and every PDF exhibit attached to the EDGAR submission. The dataset preserves the original filer-supplied filenames for the PDFs and the original EDGAR document inventory in metadata. Image files (logos, scanned signature graphics, and similar binary illustrations) are excluded. The complete submission .txt wrapper is also not redistributed inside the folder; its EDGAR URL is preserved in metadata.json for retrieval. Beyond these omissions, the record reproduces the substantive content of the original submission in full.

Initial filings versus amendments

Initial filings carry submissionType SBSE-A and typically include the full applicant-identification, schedule, and certification material along with a complete Form 7-R packet and an opinion of counsel. Amendments carry submissionType SBSE-A/A, retain the same structural shape inside primary_doc.xml, and frequently add a short summary-of-changes memo as an EX-99.35 OTHER exhibit and a Form 7-R update PDF in addition to or instead of a complete Form 7-R. Schedule sections in an amendment may report only the updated principals or arrangements rather than a full restated roster, depending on the filer's convention; combining the latest SBSE-A/A with prior filings keyed by cik and fileNo is therefore necessary to reconstruct the cumulative registration profile.

Format stability

Because the form was introduced in the structured-XML era, every record from the dataset's start date forward follows the same XML namespace, element vocabulary, and packaging convention described above; there is no legacy ASCII or pre-XML era for this form type. The XSL-rendered HTML companion has been emitted alongside the structured XML throughout, and the SEC-API metadata.json header is generated for every accession across the entire date range. Exhibit-type codes EX-99.32, EX-99.34, EX-99.35, and EX-99.36 have been the stable set used for the form's certification, opinion, supporting, and Form 7-R attachments since inception. Variation across records is driven by filer-specific content — the size of the principals roster on Schedule A, the number of third-party arrangements on Schedule B, and the volume and labeling of PDF exhibits — rather than by format-era differences.

Interpretation and extraction notes

• primary_doc.xml is the single source of structured truth for the form's payload; the XSL HTML view duplicates content and should not be parsed as an independent source.
• PDF role assignments must be made through metadata.json::documentFormatFiles[] rather than from filenames, which are filer-chosen and idiosyncratic.
• Schedule B arrangement arrays appear only when the corresponding flag in applicantThree is set; an absent array reflects a "no" answer rather than missing data.
• The filerCcc field is redacted by EDGAR in published filings (XXXXXXXX) and is not a data-quality issue.
• Address fields use EDGAR's state/country code vocabulary, including non-US codes for foreign filers, which is significant given the heavy presence of non-US bank entities among SBSD registrants.
• fileNo in entities[] is the SEC-assigned SBS file number (typically 026-xxxxx) and is the most reliable cross-filing identifier for a registered SBS dealer or major participant; CIK identifies the filer entity but does not by itself disambiguate registration status.
• Dates inside the form payload use MM-DD-YYYY for execution and arrangement dates and MM/YYYY for principals' tenure dates, which differs from the ISO-8601 timestamp used by metadata.json::filedAt.

Who Files or Publishes This Dataset, and When

Who files the record

The filer is always the applicant entity itself — a non-bank or bank legal entity registering with the SEC 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 in the dataset is one application (Form SBSE-A) or one amendment to an application (Form SBSE-A/A) submitted to EDGAR.

To use Form SBSE-A rather than the long-form Form SBSE, the applicant must satisfy two simultaneous conditions:

• It meets the SBSD or MSBSP definition under Sections 3(a)(71) and 3(a)(67) of the Exchange Act (added by Title VII of Dodd-Frank).
• It is already registered with the CFTC as a swap dealer or major swap participant. This dual-status requirement is the gating condition that makes the short-form path available.

Typical filers are large global derivatives dealers, swap-dealing affiliates of bank holding companies, broker-dealer affiliates active in equity and credit derivatives, and non-U.S. dealing entities transacting with U.S. counterparties. Both U.S. and non-U.S. entities appear in the population.

Although the form discloses information about principals, senior officers, control affiliates, and other associated persons, those individuals are not themselves filers. They are described within the registering entity's application.

When the record is created or required

Form SBSE-A is not periodic. It is event-driven and tied to the registration lifecycle.

Initial registration (Form SBSE-A). Filed once, when an entity meeting the SBSD or MSBSP definition seeks SEC registration on the basis of its existing CFTC registration. The substantive obligation to register is triggered when the entity's security-based swap activity crosses the de minimis dealing threshold or the quantitative MSBSP threshold. The compliance date for the SBSD/MSBSP regime was November 1, 2021; the dataset's October 2021 start corresponds to the opening of the EDGAR submission window in the run-up to that date. Form SBSE-A has no pre-EDGAR analog — it was implemented as an EDGAR-native filing from the start.

Amendments (Form SBSE-A/A). Filed promptly whenever previously submitted information becomes inaccurate or incomplete in any material respect, or when supplemental information is required in response to SEC review. Rule 15Fb2-1 and the form instructions impose a continuing duty to keep the registration current. Common amendment triggers include changes in legal name, control, principal place of business, senior officer roster, disciplinary history of the firm or its associated persons, and updates to certifications or schedules. There is no quarterly or annual cadence — amendments arise as the underlying facts change.

Regulatory framework

Form SBSE-A sits within the registration regime created by Section 15F of the Exchange Act (added by Title VII of Dodd-Frank) and implemented by Rule 15Fb2-1. The SEC adopted three registration forms under that rule:

• Form SBSE — long-form general application for filers not eligible for either short form.
• Form SBSE-A — short form for SBSDs/MSBSPs that are also CFTC-registered swap dealers or major swap participants. The accommodation reflects that such filers have already provided substantial information to the CFTC and the National Futures Association; SBSE-A therefore omits or condenses items already covered and asks for SEC-specific incremental disclosures plus identifying information and required certifications (including the senior officer compliance certification).
• Form SBSE-BD — short form for SBSDs/MSBSPs that are also SEC-registered broker-dealers, leveraging Form BD on file with the Commission.

A dually CFTC-registered and SEC broker-dealer entity may have access to either short form; an entity that is neither must use Form SBSE.

Important distinctions

Bank vs. non-bank SBSDs. Both can file Form SBSE-A if CFTC-registered. The form itself does not vary by bank status, though the surrounding capital, margin, and prudential frameworks differ.

Entity vs. associated persons. The legal filer is always the applicant entity. Personnel-level registration concepts (such as Form U4 for broker-dealer associated persons) operate in a different channel.

Foreign applicants. Non-resident entities meeting the SBSD or MSBSP definition through cross-border dealing activity register on Form SBSE-A if they are also CFTC-registered. Substituted compliance determinations may affect substantive obligations but not the form used.

Amendments vs. corrections. Both material updates and corrections of prior submissions surface as SBSE-A/A; the dataset does not separately label motivation.

Withdrawal and termination. An entity ceasing SBSD or MSBSP status files Form SBSE-W, not an SBSE-A/A. Withdrawal records are outside this dataset's scope, which covers only SBSE-A and SBSE-A/A submissions.

How This Dataset Differs From Similar Datasets or Filings

Form SBSE-A is one branch of the security-based swap (SBS) registration family created under Title VII of Dodd-Frank and Rule 15Fb2-1. The most useful comparisons are to the other SBSE forms, to the CFTC registration that SBSE-A explicitly leans on, and to a small set of adjacent forms whose disclosure surface partly overlaps. Periodic disclosure forms (10-K, 10-Q, 8-K) are not relevant comparisons: SBSE-A is an entry-point registration application, not periodic or event-driven disclosure.

Form SBSE (long-form SBS dealer / MSBSP registration)

SBSE is the full-length application used by SBS dealers and MSBSPs that are not registered with the CFTC. SBSE-A is its short-form sibling for the CFTC-registered cohort: same regulatory purpose, but most organizational and operational disclosure is replaced by cross-references to CFTC Form 7-R. SBSE filings are substantively richer in standalone content; SBSE-A filings are thinner by design. The two datasets cover disjoint filer populations and must be combined to obtain the full SEC-registered SBS dealer / MSBSP universe.

Form SBSE-BD (short form for SEC-registered broker-dealers)

SBSE-BD plays the same "do-not-duplicate" role as SBSE-A, but the cross-reference target is Form BD rather than CFTC Form 7-R. Disclosure structure is similar (identity, disciplinary history, associated persons, senior officer certifications), but the populations rarely overlap: SBSE-A applicants come from the futures/swaps side, SBSE-BD applicants from the broker-dealer side. Use SBSE-BD for broker-dealer-affiliated SBS dealers; use SBSE-A for CFTC-registered swap dealers extending into SBS.

Form SBSE-C (senior officer / CCO certifications)

Form SBSE-C is not a registration application. It is a Rule 15Fb6-2 certification by the senior officer and CCO, typically filed alongside or shortly after an SBSE, SBSE-A, or SBSE-BD application and re-filed when those officers change. It contains no disciplinary history, no associated-person rosters, and no entity-level identifying disclosure. It complements SBSE-A as a separate certification artifact rather than competing with it.

Form SBSE-W (withdrawal from registration)

SBSE-W is the exit-side counterpart: a minimal filing recording the fact and reasons for withdrawal of an SBS registration. It contains none of the substantive identifying or disciplinary disclosure of SBSE-A. Population-level questions about currently registered SBS dealers require netting SBSE-W exits against SBSE / SBSE-A / SBSE-BD entries.

Form SBSE-A/A (amendments to SBSE-A)

SBSE-A/A is included in this dataset. It updates the same disclosure surface as the underlying SBSE-A (identifying information, disciplinary updates, associated-person changes) and follows the standard "/A" amendment pattern: it modifies, but does not replace, the original record. SBSE-A and SBSE-A/A should be treated as a longitudinal pair within one population, not as separate datasets.

Form BD (general broker-dealer registration)

Form BD registers broker-dealers for general securities activity and serves as the cross-reference baseline for SBSE-BD, not SBSE-A. Filer population is far broader than any SBSE form, and the regulatory regime is broker-dealer activity rather than SBS activity. A single legal entity may have both Form BD and SBSE-A on file, but Form BD does not establish SEC SBS registration and is not a substitute path.

CFTC Form 7-R (CFTC swap dealer / MSP registration)

CFTC Form 7-R is the upstream CFTC registration that SBSE-A relies on. It is filed with the NFA, not EDGAR, and is therefore outside this dataset. Because SBSE-A deliberately omits content already on Form 7-R, analysts who need full organizational, ownership, or operational detail for the dual-registered cohort must pull Form 7-R from NFA sources; SBSE-A alone is informationally thinner than SBSE by design.

Form X-17A-5 / FOCUS reports

Form X-17A-5 / FOCUS reports is periodic (monthly, quarterly, annual) financial and operational condition reporting; SBSE-A is a one-time registration application with episodic amendments. FOCUS is tabular financial data (capital, balance sheet, P&L); SBSE-A is identifying, disciplinary, and personnel disclosure. They answer different questions: SBSE-A establishes who is registered; FOCUS tracks ongoing financial condition.

Form U-4 / FINRA CRD

Form U-4 is the per-individual uniform application for securities-industry registration, filed through FINRA's CRD and refreshed continuously as personnel and disclosures change. SBSE-A's associated-person section overlaps in subject matter but is an entity-level snapshot embedded in an entity application, with far less biographical and employment-history depth. Person-level disciplinary or career analysis belongs in CRD/BrokerCheck; SBSE-A only supports entity-level rosters as of filing or amendment dates.

Boundary summary

SBSE-A is distinguished within the SBSE family by three things: filer population (CFTC-registered swap dealers and MSPs), short-form scope (relies on Form 7-R rather than restating it), and lifecycle position (entry and amendment, not certification, withdrawal, or periodic reporting). SBSE covers the non-CFTC SBS cohort; SBSE-BD covers the broker-dealer cohort; SBSE-C carries certifications; SBSE-W marks exit; Form BD, Form 7-R, FOCUS, and U-4 sit in adjacent regimes that do not establish SEC SBS registration. None of these is interchangeable with SBSE-A, and any SBS-dealer population analysis that omits SBSE-A will misrepresent the CFTC-registered branch of the market.

Who Uses This Dataset

The Form SBSE-A Files Dataset is consulted by a narrow but well-defined set of professionals working on derivatives registration, counterparty onboarding, examination, and entity-level risk monitoring.

Derivatives compliance and registration teams

In-house compliance officers and registration specialists at SBS dealers and major SBS participants use peer filings as a working reference when preparing initial SBSE-A submissions and SBSE-A/A amendments. They focus on the applicant identity block (legal name, CIK, CRD/NFA identifiers, organizational form), the CFTC registration linkage that justifies short-form use, the ownership and control schedules, and the disciplinary disclosure items. Comparisons against peer drafts help calibrate disclosure granularity around statutory disqualifications and associated-person populations.

Securities and derivatives counsel

Outside and in-house counsel advising registrants research how Rule 15Fb2-1 has been applied in practice. They review how peer filers describe CFTC-registered status, treat foreign-incorporated applicants, and characterize regulatory actions and pending proceedings in the disciplinary schedules. The certifications and exhibits drive registration memos, opinion letters, and comment-response packages addressing SEC staff inquiries.

Counterparty onboarding and KYC desks

Onboarding teams at buy-side firms, prime brokers, custodians, and corporate end-users confirm a counterparty's SEC SBS dealer or major participant status before executing trades or extending lines. They consume applicant identity, the most recent SBSE-A/A accession date, control-person and associated-person disclosures that map corporate structure, and disciplinary flags that trigger enhanced due diligence. Outputs feed counterparty master records, periodic re-KYC packets, and audit evidence of regulated status.

SEC examination and enforcement staff

Examination and registration staff treat the dataset as the canonical record of who elected the short-form path and what they disclosed at application. Reviewers focus on consistency between applicant identity and CFTC records, completeness of disciplinary disclosure relative to public enforcement actions, the associated-person population subject to statutory disqualification screening, and the executed certifications. The dataset supports exam scoping, registration-renewal review, and triage of which filers warrant deeper books-and-records review.

Credit and counterparty risk teams

Credit officers at banks, asset managers, insurers, and corporate treasuries corroborate the regulatory standing of entities in their derivatives exposure inventories. They use the ownership and control schedules to assess group-level concentration and wrong-way risk, disciplinary history as a credit overlay, and the SEC-CFTC registration linkage as a status check. Outputs include counterparty credit memos, internal risk ratings, and ISDA onboarding decisions.

Market structure and OTC derivatives researchers

Academic researchers and market-structure analysts use the dataset to build longitudinal panels of the SBS dealer population since October 2021. They focus on filer identity, jurisdiction of incorporation, group structure inferred from control schedules, and the timing of SBSE-A versus SBSE-A/A filings. Outputs include working papers on dual-registration patterns, market concentration, and the effectiveness of the short-form regime, plus league tables of dealer affiliation.

Regtech and entity-intelligence vendors

Vendors building counterparty intelligence and regulatory-status monitoring products ingest the dataset as a primary source for their entity graphs. Engineering teams parse the structured metadata and PDF/HTML attachments to extract identifiers (CIK, legal name, CRD/NFA), associated-person fields, and disciplinary flags. The dataset supports automated change detection on SBSE-A/A amendments and alerts when a counterparty's disclosed control structure or disciplinary history materially shifts.

Litigation support and investigative analysts

Investigators at law firms and litigation-support consultancies build entity dossiers and timelines involving SBS dealers. They focus on disciplinary schedules, named associated persons, signatory blocks on certifications, and the chronology of originals versus amendments to detect when material facts changed. Outputs feed witness identification, deposition preparation, and evidentiary exhibits.

LLM and RAG developers for regulatory retrieval

Teams building retrieval-augmented systems for derivatives compliance and counterparty research use the dataset as a corpus. They consume the structured XML metadata, parsed schedule text, standardized field names, and parent-amendment linkages for temporal reasoning. The dataset supports natural-language tools that answer specific questions about a counterparty's registered status without manually pulling each accession.

Across roles, the same core fields drive the workflow: applicant identity, CFTC linkage, ownership and control schedules, disciplinary disclosure, and the executed certifications. Compliance, legal, examination, and onboarding teams treat the dataset as an operational record of short-form SBS registration; researchers, regtech vendors, and AI developers use it as structured input for population-level analysis.

Specific Use Cases

The dataset's value is operational: it is the canonical SEC record of which CFTC-registered swap dealers and major participants have elected the short-form path under Rule 15Fb2-1, what they disclosed, and how that disclosure has changed over time. The following workflows show how the structured XML payload, metadata header, and PDF exhibits are actually consumed.

Building and maintaining an SBS dealer registry

Counterparty intelligence teams build a master list of SEC-registered SBS dealers and major participants by sweeping every record's metadata.json::entities[] for companyName, cik, irsNo, fileNo (the 026-xxxxx SBS file number), stateOfIncorporation, and tickers[], then joining to formData.applicant.applicantOne for applicantNFANumber, applicantUic (LEI), and contact addresses. Keying on fileNo and rolling forward the latest SBSE-A/A per registrant produces a current, deduplicated registry suitable for KYC packets, ISDA onboarding, and counterparty master records.

Detecting material changes on amendments

Onboarding and regtech monitoring pipelines diff each new SBSE-A/A against the prior accession for the same fileNo, comparing scheduleA.scheduleAInfo[] (principals roster), scheduleB.sectionTwo arrangement arrays (Items 13A, 13B, 14, 15), and the applicantTwo flag battery. The accompanying EX-99.35 OTHER summary-of-changes PDF is parsed for human-readable confirmation. The output is an alert stream flagging principal departures, new clearing or custody arrangements, control-agreement changes, and shifts in financing affiliates.

Reconstructing group structure and control chains

Market-structure and credit analysts extract controlThroughAgreementDetails.controlThroughAgreement[] (Item 14) and whollyOrPartiallyFinanceDetails.whollyOrPartiallyFinance[] (Item 15) entries, harvesting firmOrOrganizationName, firmCikNumber, firmCrdNo, firmUic, and firmAddress for each related party. Linking these across all SBSE-A filers yields a parent-affiliate-financier graph used for group-level exposure aggregation, wrong-way-risk screening, and dealer-affiliation league tables.

Mapping outsourced operations and venue dependencies

Examination scoping and operational-risk reviewers pull recordsKeptDetails.recordsKept[] (Item 13A) and onBehalfDetails.onBehalf[] (Item 13B) to identify the third-party books-and-records custodians, trading venues, clearing brokers, and service providers each registrant relies on. Aggregating firmOrOrganizationName and descriptionArrangement across the population highlights concentration in a small set of vendors and supports targeted books-and-records examinations and vendor-risk concentration reports.

Officer and principal screening

Compliance and litigation-support analysts harvest scheduleA.scheduleAInfo[] for each principal's individualName, titleOrStatus, dateBeganWorking, nfaIdentificationNo, and crdNo, plus applicantOne.chiefComplianceOfficer and contactEmployee blocks. The resulting roster feeds CRD/BrokerCheck lookups, statutory-disqualification screening, and signatory-history timelines built from the formData.execution block (signature, nameOfPersonSigning, titleOfPersonSigning, date).

Foreign-filer and substituted-compliance analysis

Researchers studying the cross-border footprint of the SBS dealer population filter records on entities[].stateOfIncorporation (including non-US codes such as X0 and 2M), applicantTwo.isNonResidentEntity, applicantTwo.foreignFinancialRegulatory, and the optional description3C substituted-compliance block. Combined with the EX-99.34 OPIN COUNSL opinion-of-counsel PDFs addressing books-and-records location, this supports working papers on jurisdictional distribution, regulator-overlap patterns, and the practical reach of substituted compliance.

RAG corpus for derivatives-registration questions

Teams building retrieval systems for derivatives compliance ingest primary_doc.xml as the structured truth source, attach the EX-99.32 certifications, EX-99.34 opinions, EX-99.35 summary memos, and EX-99.36 Form 7-R packets as linked documents per accession, and key chunks by accessionNo, fileNo, and filedAt. The result answers natural-language questions such as "who is the CCO at this counterparty," "when did this dealer last amend its principals roster," or "which third party holds this filer's books and records" without manual EDGAR retrieval.

Dataset Access

The Form SBSE-A Files Dataset can be accessed in three ways: through the dataset index JSON API for metadata and container listings, as a single full archive download, or as individual container files.

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

This endpoint returns dataset metadata including the name, description, last update timestamp, earliest sample date, total records and total size, form types covered (SBSE-A and SBSE-A/A), container format (ZIP), and the file types contained (XML, PDF, JSON, HTML). It also provides the full dataset download URL and a list of container files, where each entry includes the container key, size, record count, last updated timestamp, and a direct download URL. This endpoint does not require an API key. It can be polled to monitor which containers were updated in the most recent refresh and to decide which containers to re-download incrementally.

Example response:

          1
          {
        

          2
            "datasetId": "1f13365b-9ae0-69c1-aef0-ea3f064fe62d",
        

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

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

          5
            "updatedAt": "2026-05-02T03:05:15.732Z",
        

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

          7
            "totalRecords": 4100,
        

          8
            "totalSize": 3653090053,
        

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

          10
            "containerFormat": "ZIP",
        

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

          12
            "containers": [
        

          13
              {
        

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

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

          16
                "size": 13818783,
        

          17
                "records": 154,
        

          18
                "updatedAt": "2026-05-02T03:05:15.732Z"
        

          19
              }
        

          20
            ]
        

          21
          }
        

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

Downloads the complete dataset, covering all SBSE-A and SBSE-A/A filings from October 2021 to present, as a single ZIP archive. This endpoint requires an API key.

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

Downloads one individual monthly container instead of the full dataset. Use the container key values returned by the index JSON API to construct the path. This endpoint requires an API key.

Frequently Asked Questions

What forms does this dataset cover?

The dataset covers Form SBSE-A (the short-form initial application for SEC registration as a security-based swap dealer or major security-based swap participant) and Form SBSE-A/A (amendments to a previously submitted SBSE-A). It does not include Form SBSE, Form SBSE-BD, Form SBSE-C, or Form SBSE-W, which sit in adjacent slots of the SBS registration family.

What does one record in this dataset represent?

One record corresponds to a single Form SBSE-A or Form SBSE-A/A submission as filed on EDGAR, identified by its 18-digit accession number. The record is a folder (named after the accession) containing metadata.json, the structured primary_doc.xml, the XSL-rendered HTML companion under xslSBSE-A_X01/, and every PDF exhibit attached to the EDGAR submission.

Who is required to file Form SBSE-A?

The filer is the applicant entity itself — a legal entity registering with the SEC as a security-based swap dealer or major security-based swap participant under Section 15F of the Exchange Act that is also already registered with the CFTC as a swap dealer or major swap participant. That dual-status condition is what makes the short-form path under Rule 15Fb2-1 available. Typical filers include large global derivatives dealers, swap-dealing affiliates of bank holding companies, broker-dealer affiliates active in equity and credit derivatives, and non-U.S. dealing entities transacting with U.S. counterparties.

When are Form SBSE-A and SBSE-A/A filings made?

Form SBSE-A is event-driven, not periodic. An initial SBSE-A is filed once when the entity seeks SEC registration. SBSE-A/A amendments are filed promptly whenever previously submitted information becomes inaccurate or incomplete in any material respect, or when the SEC requests supplemental information; there is no quarterly or annual cadence.

What time period does the dataset cover?

The dataset begins on October 1, 2021 — the opening of EDGAR's submission window in the run-up to the November 1, 2021 SBSD/MSBSP compliance date — and is updated continuously as new applications and amendments are filed. Form SBSE-A has no pre-EDGAR analog and was implemented as an EDGAR-native, structured-XML filing from the start.

What file formats are inside each record?

Each record is delivered inside a ZIP container and contains four kinds of file: a JSON metadata header (metadata.json), a structured XML form payload (primary_doc.xml), an HTML rendering of that form (under xslSBSE-A_X01/), and one or more filer-supplied PDF exhibits. PDF roles are identified by EDGAR exhibit-type codes (EX-99.32 certifications, EX-99.34 opinions of counsel, EX-99.35 other supporting material, and EX-99.36 NFA Form 7-R packets) recorded in metadata.json::documentFormatFiles[].

How does this dataset differ from Form SBSE filings?

Form SBSE is the long-form application used by SBS dealers and MSBSPs that are not registered with the CFTC. Form SBSE-A is the short-form sibling for the CFTC-registered cohort, replacing most organizational and operational disclosure with cross-references to CFTC Form 7-R. The two datasets cover disjoint filer populations and must be combined to obtain the full SEC-registered SBS dealer / MSBSP universe.