The Form SBSEF Files Dataset is the collection of every Form SBSEF and Form SBSEF/A submission accepted by EDGAR — the SEC application by which an entity registers, or amends its registration, as a security-based swap execution facility (SBSEF) under Section 3D of the Securities Exchange Act of 1934 and Regulation SE (17 CFR 242.800 through .835). One record in the dataset is one accession: a self-contained folder, named by the 18-digit dashless EDGAR accession number, that bundles a canonical metadata.json submission summary, the structured primary_doc.xml form body, an SEC-rendered XHTML view, and the exhibit attachments (almost always PDFs) the filer chose to attach. The filer of every record is the SBSEF entity itself, typically a Delaware-domiciled LLC or corporation holding an SEC file number in the dedicated 039-100xxx series. Form SBSEF entered service on EDGAR as a born-digital, XML-native form in 2024, and the dataset covers filings from August 2024 onward — the first month in which any Form SBSEF was accepted by EDGAR. The dataset is distributed as monthly ZIP containers in the file formats JSON, XML, and PDF.
Programmatically retrieve the full list of dataset archive files, download URLs and dataset metadata.
Dataset Index JSON API
Download the entire dataset as a single archive file.
Download Entire Dataset:
Download a single container file (e.g. monthly archive) from the dataset.
Download Single Container:
The dataset captures the full population of SBSEF registration filings on EDGAR — both the initial application form (SBSEF) and the amendment variant (SBSEF/A) — covering filings from August 2024 to present. Form SBSEF is the application prescribed by the SEC under Section 3D of the Exchange Act (15 U.S.C. 78c-4) and Regulation SE for any entity seeking registration as a security-based swap execution facility. The form implements the security-based swap trading-platform regime mandated by Title VII of the Dodd-Frank Wall Street Reform and Consumer Protection Act. An SBSEF is a multi-participant trading facility on which security-based swaps may be traded, subject to a set of statutory Core Principles governing rule compliance, fair access, governance fitness, financial resources, recordkeeping, antitrust considerations, conflict-of-interest mitigation, system safeguards, timely publication of trading information, and rule enforcement. The form is identified on EDGAR by OMB Number 3235-0793.
The two form variants populating the dataset play distinct roles. SBSEF is the initial registration application; a new applicant files this once. SBSEF/A is an amendment, used both to update cover-page information and, far more commonly, to refile or revise one or more of the form's exhibits when the registrant's rules, governance documents, fitness standards, compliance procedures, financial resources, or service agreements change. Amendments dominate the dataset because the universe of registered SBSEFs is small and largely stable, while their attached rulebooks and procedures are revised continuously.
For each accession the dataset includes the metadata.json summary, the raw primary_doc.xml, the SEC-supplied XHTML rendering of that payload under xslSBSEF_X01/, and every exhibit attachment the filer included with that submission. Image files are excluded by dataset policy. The dataset is distributed as monthly ZIP containers, and the underlying file types present in the records are JSON, XML, and PDF.
One record in the Form SBSEF Files dataset is a single EDGAR submission of either Form SBSEF or Form SBSEF/A, materialized on disk as a self-contained folder named by the 18-digit EDGAR accession number with the dashes stripped (for example 000149315225003438). Each folder bundles the EDGAR-supplied artifacts for that accession: a canonical metadata.json summary of the submission, the raw machine-readable primary_doc.xml carrying the structured form data, an SEC-rendered XHTML view of that XML under xslSBSEF_X01/primary_doc.xml, and zero or more exhibit attachments — almost always PDFs — corresponding to the Regulation SE exhibits the filer chose to attach to that accession. The accession folder is the atomic unit of the dataset; everything inside it constitutes one regulatory event in the life of an SBSEF's registration with the Commission.
Inside one accession folder, the content is organized in three layers:
metadata.json. A flat JSON description of the filing's identity, the filer entity, the EDGAR-acknowledged receipt time, and the inventory of constituent documents.primary_doc.xml together with its rendered sibling xslSBSEF_X01/primary_doc.xml. The raw XML carries the structured cover-page data; the XSL output is the human-readable XHTML view of the same content.This maps cleanly onto the EDGAR submission concept: one header, one primary form, and a variable set of exhibit documents, all bundled under one accession number.
metadata.json — the submission headermetadata.json is the per-accession header carrying the canonical identification and inventory of the submission. Its fields include:
formType — SBSEF or SBSEF/A.accessionNo — the dashed EDGAR accession (for example 0001493152-25-003438). The on-disk folder name uses the dashless form.filedAt — ISO-8601 timestamp with an explicit US/Eastern offset (e.g. 2025-01-23T17:19:12-05:00), the EDGAR-acknowledged receipt time.description — typically Form SBSEF - Application for Registration of Security-based Swap Execution Facility, suffixed with [Amend] for SBSEF/A.linkToFilingDetails, linkToHtml, linkToTxt, linkToXbrl — absolute EDGAR URLs pointing respectively at the rendered form view, the filing-index page, the SGML submission envelope, and (for SBSEF, empty) the XBRL instance.id — an internal 32-character hash unique per record.documentFormatFiles[] — the enumerated inventory of constituent documents. Each entry carries a sequence, a size in bytes (string-typed), an absolute documentUrl, a type field encoding the EDGAR exhibit category (see the exhibits subsection below), and an optional human-readable description. The form itself is represented by two physical rows sharing sequence "1" — one for the raw primary_doc.xml and one for the XSL-rendered xslSBSEF_X01/primary_doc.xml. A separate row with a single-space sequence and single-space type describes the existence of the full submission text envelope on EDGAR.entities[] — typically a one-element array describing the filer: companyName (with the EDGAR-supplied (Filer) role suffix preserved), unpadded numeric cik, the SEC fileNo drawn from the dedicated SBSEF series 039-100xxx, the nine-digit irsNo (EIN), stateOfIncorporation, fiscalYearEnd as MMDD, act set to "34" for the Securities Exchange Act, filmNo, and a type field duplicating the top-level formType.seriesAndClassesContractsInformation — empty for SBSEF; present for schema consistency with the broader EDGAR JSON envelope used across the dataset family.dataFiles — typically empty. When a filer chooses to attach a structured-data XSD schema for the Exhibit I financial-resources disclosure (document type EX-99.SBSEF.SCH), the schema reference appears here.primary_doc.xml — the structured form bodyprimary_doc.xml is the SEC's canonical machine-readable representation of the Form SBSEF cover page. Its root element is <edgarSubmission> in the namespace http://www.sec.gov/edgar/sbseffiler, with companion namespaces declared for the SBSEF exhibit grammars and shared common types:
http://www.sec.gov/edgar/sbsefcommonhttp://www.sec.gov/edgar/document/sbsef/exhibita (Exhibit A — organizational chart)http://www.sec.gov/edgar/document/sbsef/exhibitb (Exhibit B — officers and directors)http://www.sec.gov/edgar/document/sbsef/exhibitgmn (grouped grammar for Exhibits G, M, N)http://www.sec.gov/edgar/document/sbsef/exhibitt (Exhibit T)http://www.sec.gov/edgar/commonThe XSL rendering directory name xslSBSEF_X01 indicates version X01 of the SBSEF transform; the namespace path and version are stable handles for downstream parsers.
The XML has two top-level children.
<headerData> — always present. It contains:
<submissionType> repeating the form type (SBSEF or SBSEF/A).<filerInfo> with <filer><filerCredentials><cik> (zero-padded to 10 digits, in contrast to the unpadded CIK in metadata.json.entities[].cik) and <ccc>, the filer's confidential CIK-confirmation code. In published archives <ccc> is always redacted to XXXXXXXX; this is an SEC redaction, not a parsing failure.<flags> carrying <overrideInternetFlag> (boolean) and <liveTestFlag> (LIVE for production, TEST for sandbox).<formData> — optional. Amendments that change only an exhibit and leave the cover-page facts intact frequently omit <formData> entirely; in that case the XML carries only <headerData> and downstream code must not require <principalInfo>. When present, <formData> carries:
<principalInfo> — the applicant identity block: <applicantName>, <street1>, <street2>, <city>, <stateOrCountry>, <zipCode>. This is the registered principal place of business of the facility operator.<principalInfo><amendedItemsList> (on SBSEF/A only) — a free-text, filer-authored enumeration of which exhibits are being amended in this filing. Capitalization and punctuation are inconsistent across filers and over time (an actual example: Exhibits M-1 Rulebook,, Exhibit o-1 Written Supervisory Procedure Manual, Exhibit I, Financial Resources, and Cover Letter). The list of items named here can legitimately exceed the set of exhibit binaries actually attached on disk.<generalInfo><businessInfo> — optional block carrying <businessName> and <previousBusinessName> when a facility operates under a name other than the registered legal entity. Often empty or whitespace-only.The Form SBSEF cover page also asks the applicant to identify a contact agent for SEC correspondence and to specify the classes of security-based swaps the facility intends to list (for example single-name credit default swaps, narrow-based-index CDS, equity swaps). These items appear in the XHTML rendering of the form for initial SBSEF filings; for the amendment-dominant population they are typically inherited from the prior filing and not re-asserted in <formData>.
xslSBSEF_X01/primary_doc.xml — the XHTML renderingThis file lives in a subfolder named after the SEC's XSL stylesheet identifier (xslSBSEF_X01). Despite the .xml extension, the payload is XHTML 1.0 Strict — the browser-renderable view EDGAR serves on its filing-details page. The XHTML preamble shows the SEC header text FORM SBSEF UNDER THE SECURITIES EXCHANGE ACT OF 1934, the OMB number 3235-0793, and labeled sections for filer information, contact agent, classes of security-based swaps, and amended items. It is content-equivalent to primary_doc.xml and is provided for direct human consumption; structured extraction should prefer the raw XML.
The substantive content of a Form SBSEF filing lies almost entirely in its exhibits, which are filed as separately attached documents (predominantly PDFs in this dataset). The exhibit slots prescribed by the Form SBSEF instructions, anchored in Regulation SE and the SBSEF Core Principles, include:
EX-99.SBSEF.SCH XSD schema may be referenced.In documentFormatFiles[].type, these map to EDGAR's EX-99.{letter}.SBSEF taxonomy — for example EX-99.M.SBSEF for the rulebook, EX-99.TRANSMTL.SBSEF for the cover letter, and EX-99.SBSEF.SCH for the financials schema. Exhibit binaries are named freely by the filer (coverletter.pdf, exhibit-m.pdf, etc.); the authoritative classification lives in the type code, not the filename.
Per accession, only the exhibits actually attached on that submission appear on disk. SBSEF/A amendments are commonly thin — a single exhibit PDF, or no exhibit binaries at all when the amendment is itself entirely cover-page metadata.
Several items that are conceptually part of the EDGAR submission are not materialized as on-disk files in the accession folder:
.txt SGML submission envelope — the single bundled text wrapper EDGAR creates around every filing — is referenced in documentFormatFiles[] (sequence " ", type " ", description Complete submission text file) but is not extracted into the folder. Parsers should treat that row as a pointer to EDGAR, not a guarantee of an on-disk file.dataFiles (such as an EX-99.SBSEF.SCH XSD for the Exhibit I financials) may be referenced in metadata without being included on disk. Test for existence before opening.The two form types are structurally the same — same XML schema, same exhibit taxonomy, same <edgarSubmission> root — but differ in role:
<formData> block describing the applicant from scratch (principal name and address, contact agent, classes of security-based swaps to be traded, and the complete set of exhibits attached or incorporated by reference). The initial registration is the anchor.<formData> is present and <principalInfo><amendedItemsList> enumerates the affected items in filer-authored prose. If only exhibits change, <formData> is often omitted entirely and the amendment consists of a <headerData>-only XML plus the re-attached exhibit binaries. The amendedItemsList and the actual on-disk exhibit set need not match: filers may cite exhibits they are revising and re-attach only a subset, or attach a cover letter as the sole binary.The dataset's amendment-heavy population reflects operational reality: registrations are filed once, but rulebooks, compliance manuals, fitness standards, and Core Principle compliance documentation are revised on a continuing basis.
Form SBSEF entered EDGAR in 2024 as a born-digital, XML-native form. Unlike older SEC form families that transitioned across ASCII, HTML, and XBRL eras, SBSEF is delivered from inception as:
primary_doc.xml) under the sbseffiler namespace and the xslSBSEF_X01 rendering stylesheet (version X01),The XSL transform identifier (SBSEF_X01) and the namespace versions are the structural-versioning handles to monitor if and when the SEC publishes a revised schema.
Several characteristics warrant care during extraction or analysis:
000149315225003438); the same accession appears with dashes in metadata.json.accessionNo (0001493152-25-003438). Joining across the two representations requires normalization.entities[].cik and the zero-padded 10-digit CIK in <filerCredentials><cik> refer to the same entity and should be normalized for joins.<ccc>XXXXXXXX</ccc> is intentional SEC redaction, not a parse error.<formData>: many amendments ship only <headerData>. Do not require <principalInfo> to be present.documentFormatFiles[] carries two entries with sequence "1", one for the raw primary_doc.xml and one for the XSL-rendered xslSBSEF_X01/primary_doc.xml. These describe two physical files of the same logical document; the rendered row often has size=" " because no separately stored byte size exists.Complete submission text file row and dataFiles schema references can describe documents that are not materialized into the folder. Test for existence before opening.<amendedItemsList> is free-text with inconsistent punctuation and capitalization across filers; do not parse it as a controlled vocabulary. The authoritative exhibit-type signal is the type code on each documentFormatFiles[] entry.039-100xxx series, a reliable filter for confirming the SBSEF identity of a filer.filedAt preserves an explicit -05:00 (or -04:00 during daylight time) offset reflecting EDGAR's US/Eastern receipt clock; preserve the offset for accurate temporal ordering.The filer of every Form SBSEF record is the security-based swap execution facility ("SBSEF") itself — the legal entity that operates the multilateral trading platform on which security-based swaps are executed or traded by multiple participants. It is never the parent holding company, the dealer or institutional participants who transact on the platform, or the officers and owners named inside the form's exhibits.
In the observed 2024–2025 cohort, every applicant is a Delaware-domiciled LLC or Inc. holding an SEC file number in the dedicated 039-100xxx range. The filer universe is narrow and largely consists of interdealer-broker-affiliated venues already registered with the CFTC as swap execution facilities, now adding the SEC-side security-based swap line of business: Bloomberg SEF LLC, Tradition SEF LLC, TW SEF LLC (Tradeweb), GFI Swaps Exchange LLC, tpSEF Inc. (Tullett Prebon), GLMX Technologies LLC, and WEMATCH.LIVE LLC, among others. The commercial population eligible to register is small because the underlying products — chiefly single-name credit default swaps and equity-based swaps on a single security or narrow-based index — trade on only a handful of venues globally.
Form SBSEF is the registration application required by Section 3D of the Securities Exchange Act of 1934 (15 U.S.C. 78c-4), a provision added by Title VII of the Dodd-Frank Wall Street Reform and Consumer Protection Act of 2010. Title VII split derivatives oversight between the CFTC (jurisdiction over "swaps") and the SEC (jurisdiction over "security-based swaps"). Section 3D requires any person operating a facility for the trading or processing of security-based swaps to register as an SBSEF and codifies fifteen statutory Core Principles governing compliance, market surveillance, financial integrity, governance, system safeguards, recordkeeping, and disciplinary procedures.
The implementing rules sit in Regulation SE, codified at 17 CFR 242.800 through 242.835, adopted by the SEC on November 2, 2023 in Release No. 34-99068, with phased compliance dates beginning in 2024. The first live Form SBSEF filings on EDGAR appeared in August 2024, which is why the dataset's earliestSampleDate is 2024-08-01 — the form does not exist in EDGAR before that point.
A Form SBSEF (the unamended type) is triggered when an entity intends to operate, or to begin permitting trading of security-based swaps on, a multilateral platform within the SEC's jurisdiction. Filing and Commission acceptance are a precondition to lawful operation under Section 3D and Rule 803, subject to the conditional registration accommodations made available to platforms transitioning from CFTC-only SEF status during the initial 2024 compliance window.
A Form SBSEF/A (amendment) is triggered by any of three event classes:
<amendedItemsList> enumerating what changed.Amendments are event-driven, not scheduled. The January 2025 sample shows eight different SBSEFs each filing at least one SBSEF/A that month, most carrying only a single exhibit attachment.
For initial applications, the Commission has a 90-day statutory review window from receipt of a complete Form SBSEF to grant, deny, or conditionally grant registration. The window may be extended where the application is materially deficient or where the applicant consents. Registration may be granted unconditionally or conditionally — the conditional path was used heavily in the 2024 cohort to accommodate CFTC-registered SEFs coming into full SEC compliance over a transition period.
Form SBSEF is a registration filing, not a periodic report: there is no quarterly or annual cadence. Once registered, an SBSEF's ongoing obligations migrate to other Regulation SE filings (rule self-certifications, product listings, CCO reports, financial reporting), which are not included in this dataset.
Form SBSEF is filed, not furnished — it is a substantive application subject to SEC review, certified by the applicant, and remains the operative registration document until withdrawn under Rule 807 or terminated by Commission action.
Each of these adjacent regimes has its own Title VII form, its own SEC file-number series, and its own dataset.
Several SEC forms and one parallel CFTC regime cover adjacent subject matter — trading-venue registration, security-based swap participants, and ongoing SRO rule changes — and are frequently confused with Form SBSEF. The comparisons below isolate the precise statutory, functional, and structural differences.
Form SEF is the CFTC analogue for swap execution facility trading non-security-based swaps, authorized by CEA Section 5h (Dodd-Frank Section 733) and implemented under 17 CFR Part 37. The exhibit template (governance, rulebook, compliance procedures, financial resources, Core Principle compliance) is nearly identical in shape, and many filer names overlap one-for-one — Tradition SEF, Bloomberg SEF, TW SEF, GFI Swaps Exchange, tpSEF — because these entities operate dual-registered venues.
Key differences:
039-100xxx range (visible in entities[].fileNo in sample metadata); CFTC SEFs have no SEC file number for their SEF activity.Form 1 registers a national securities exchange under Section 6 of the Exchange Act. Both forms register an SRO trading venue supervised directly by the SEC and both ship exhibit-heavy governance and rulebook content.
Key differences:
Form ATS (and the NMS-stock variant Form ATS-N) registers an alternative trading system operated by a broker-dealer under Regulation ATS. Both forms register non-exchange trading venues, which is the primary source of overlap.
Key differences:
The Form SBSE / SBSE-A / SBSE-BD family registers security-based swap dealers (SBSDs) and major security-based swap participants (MSBSPs) under Section 15F of the Exchange Act. It shares the "security-based swap" subject and Dodd-Frank lineage with Form SBSEF.
Key differences:
008- series file numbers (BD-style); SBSEF filers use the 039-100xxx range. Other variants in the family include SBSE-C and SBSE-W.Form CA-1 registers clearing agencies under Section 17A. Like Form SBSEF, it registers post-Dodd-Frank market infrastructure and ships an exhibit-heavy package on governance, rules, financial resources, and risk-management.
Key differences:
Form SDR registers SBS data repositories under Section 13(n) and is the closest "infrastructure cousin" within the SBS regime.
Key differences:
Once an SBSEF is registered, ongoing rulebook changes are filed on Form 19b-4 under Section 19(b), the same mechanism used by exchanges and clearing agencies.
Key differences:
SBSEF/A is the amendment variant within this dataset (and dominates it — all eight January 2025 records observed are SBSEF/A). It follows the same SEC amendment convention as other /A forms: same filer, new accession, modifying or restating exhibits.
Key differences:
<amendedItemsList> element inside primary_doc.xml names the affected exhibits (e.g., "Exhibits M-1 Rulebook, Exhibit O-1 WSP Manual, Exhibit I Financial Resources").Useful alongside, but not substitutes for, Form SBSEF Files on the SEC Datasets platform:
Datasets sometimes grouped with SBSEF by name but without substantive overlap: Form D (private-offering exemption notices) and Form 1-A (Regulation A offering statements). Both are unrelated to trading-venue infrastructure and should not be treated as adjacent.
Form SBSEF Files is the only SEC dataset capturing initial registration applications, with supporting exhibits, for security-based swap execution facilities. It is distinguished from neighbors along four verifiable axes:
039-100xxx file-number range; CFTC Form SEF filings for the same operating entities are entirely outside this dataset.Adjacent datasets enrich context (especially Form 19b-4 for ongoing rule changes and Form SBSE for the counterparty side of the SBS market), but none substitutes for the registration-level content this dataset uniquely contains.
Form SBSEF registration packages bundle rulebooks, governance and officer exhibits, compliance manuals, financial-resources statements, and lists of swap classes traded. The roles below each work from a different slice of that bundle.
Lawyers advising applicants and registrants under Regulation SE work primarily from Exhibit M (rulebook), Exhibit L (Core Principle compliance narrative), and the amendedItemsList field inside primary_doc.xml. They redline client drafts against accepted peer language, build comfort opinions on whether a protocol qualifies as a Required Transaction or Permitted Transaction, and track SBSEF/A amendments to see which provisions the SEC has pushed registrants to revise post-filing.
CCOs and supervisory-procedures staff use Exhibit O (compliance manual / written supervisory procedures), Exhibit C (fitness standards), and Exhibit S (trade data maintenance) to benchmark their own surveillance, error-trade, and disciplinary frameworks. Swap-dealer and prime-broker compliance teams pull the same files from venues their desks access to map participation criteria, position limits, and block-trade thresholds into internal onboarding and trade-supervision systems.
Quants and microstructure researchers at sell-side strategy desks and academic finance groups read rulebook PDFs and the classes-of-swaps disclosures to typologize order-book versus RFQ design, name give-up rules, minimum quote sizes, and cross-trade priority. They join this with TRACE/SDR trade data to test execution-quality and liquidity hypotheses across competing venues.
Product and strategy teams at rival SEFs, ATSs, inter-dealer brokers, and exchanges monitor SBSEF/A filings for fee-schedule changes, new listed swap classes, and ownership or affiliation disclosures in the governance exhibits. The output is win/loss tracking on participant migration and roadmap input on which instrument classes to add.
Clearing-agency risk and dealer credit/market-risk teams use Exhibit I (financial resources), Exhibit A (organizational chart), Exhibit B (officers and directors), and Exhibit N (third-party service agreements) to scope which venues to accept, what operational and BCP controls each represents, and whose surveillance feeds to connect for wash-trade and manipulation detection.
Legal-ops, derivatives-trading, and counterparty-onboarding staff at asset managers, hedge funds, pensions, and insurers read the rulebook, participation criteria, financial-eligibility thresholds, and arbitration/disciplinary sections before signing a participant agreement. The dataset feeds onboarding checklists and internal credit-committee memos.
Knowledge-management and precedent librarians at derivatives-practice groups index rulebooks, conflicts policies, emergency rule provisions, and fee schedules across the full SBSEF filing population. Associates mine this corpus to draft client exhibits efficiently and to show clients the range of accepted language for contested items such as impartial access and cross-trade restrictions.
Pre-sales and product teams at matching-engine, surveillance, KYC, and reg-reporting vendors use Exhibit N (third-party service agreements) and the operations narrative inside Exhibit O to identify which venues use which incumbent stacks, target displacement opportunities, and tailor integration proposals.
Consultants advising registrants, trade associations, and regulators use the full population of SBSEF and SBSEF/A filings to map common drafting patterns, divergent Core Principle interpretations, and SEC-CFTC harmonization gaps versus the CFTC SEF regime. Output is comment letters, white papers, and rule-making briefings.
M&A teams at venue holding companies and infrastructure investors use Exhibit A (org chart), Exhibit B (officer and director lists), and the file-number range 039-100xxx to size the SBSEF universe, identify ownership ties, and screen acquisition or partnership targets.
Across these roles, lawyers and CCOs work from the rulebook and compliance-manual exhibits; researchers and competitive-intel teams work from the swap-class and trading-protocol disclosures; risk and corp-dev teams work from the financials, officer lists, and governance exhibits; vendors and buy-side onboarding teams work from the operations and participation-criteria sections. The filing population is small but each accession is dense, and the SBSEF/A amendment trail reveals which provisions matter most.
Each use case below ties to specific exhibits or fields inside a Form SBSEF or SBSEF/A accession folder.
Tracking which rulebook provisions the SEC pressures registrants to revise. Parse the <amendedItemsList> element in primary_doc.xml across every SBSEF/A accession for a given filer CIK, then diff successive Exhibit M (rulebook) and Exhibit O (written supervisory procedures) PDFs. The output is a per-registrant timeline of contested provisions — impartial access language, error-trade windows, block-trade thresholds — that derivatives counsel use to anticipate staff comments on new applications.
Benchmarking participant-access and fitness criteria across the SBSEF population. Extract participation, eligibility, and fitness sections from Exhibit C (fitness standards) and Exhibit M (rulebook) across all filers in the 039-100xxx file-number range. Buy-side onboarding teams and CCOs use the resulting comparison table to size where their own credit, capital, and disciplinary thresholds sit against accepted peer language before signing participant agreements.
Mapping third-party vendor footprints across SBS execution venues. Pull Exhibit N (material third-party service agreements) from each accession folder and tag named clearing, market-data, surveillance, and matching-engine providers per venue, joined on filer CIK. Vendor sales engineers use the resulting incumbent map for displacement targeting; clearing-agency risk teams use it to scope operational dependencies and surveillance-feed connectivity.
Building a governance and ownership graph of registered SBSEFs. Combine Exhibit A (organizational chart), Exhibit B (officers, directors, principal shareholders), and the entities[] block in metadata.json (CIK, EIN, state of incorporation) across every applicant. Corporate development and competitive-intelligence teams use the resulting affiliation graph to identify dual-registered SEF/SBSEF operators, common ultimate parents, and director interlocks among interdealer-broker-affiliated venues.
Monitoring new swap classes and venue scope changes in near-real-time. Watch the EDGAR feed for new SBSEF/A accessions, parse the classes-of-security-based-swaps section in the XHTML rendering, and compare against the previously asserted scope for that CIK. Product teams at rival SEFs and ATSs use the output for win/loss roadmap input; researchers feed it into venue-coverage tables joined to SDR trade data for execution-quality studies.
Assessing Financial Resources Core Principle compliance per facility. Extract Exhibit I (financial resources) PDFs, plus any referenced EX-99.SBSEF.SCH structured schema in dataFiles, and track each registrant's stated one-year operating cost coverage across successive SBSEF/A amendments. Dealer-bank credit and clearing-agency risk teams use the resulting series to decide which venues to connect to and at what operational concentration.
Reconstructing the full registration record of a single SBSEF. Group all SBSEF and SBSEF/A accessions by filer CIK and order by the filedAt timestamp (preserving the US/Eastern offset) to assemble the initial application plus every amendment into one chronological dossier. Knowledge-management teams at derivatives law firms use the assembled dossier as the canonical precedent record for that registrant when drafting comparable exhibits for new applicants.
The Form SBSEF Files Dataset is distributed as monthly ZIP container files covering filings from August 2024 onward. Each container holds one folder per filing, named after the 18-digit SEC accession number (e.g. 000114420424123456). Inside each folder you will find metadata.json (filing-level metadata), primary_doc.xml (the structured SBSEF submission), an xslSBSEF_X01/ directory containing the XHTML rendering of the form, and any exhibit PDFs attached to the filing.
Dataset Index JSON API: https://api.sec-api.io/datasets/form-sbsef-files.json
This endpoint returns the dataset's metadata along with the full list of monthly ZIP containers. Each container entry includes its size, record count, S3 key, last-updated timestamp, and a direct download URL. Use it to discover which monthly containers exist and to monitor which ones changed in the most recent refresh, so you can incrementally pull only updated files. This endpoint does not require an API key.
1
{
2
"datasetId": "1f13365b-9ae0-6a57-ab19-3ea51583ea35",
3
"datasetDownloadUrl": "https://api.sec-api.io/datasets/form-sbsef-files.zip",
4
"name": "Form SBSEF Files Dataset",
5
"updatedAt": "2026-04-16T08:46:34.557Z",
6
"earliestSampleDate": "2024-08-01",
7
"totalRecords": 55,
8
"totalSize": 6732704,
9
"formTypes": ["SBSEF", "SBSEF/A"],
10
"containerFormat": "ZIP",
11
"fileTypes": ["XML", "JSON", "PDF"],
12
"containers": [
13
{
14
"downloadUrl": "https://api.sec-api.io/datasets/form-sbsef-files/2026/2026-03.zip",
15
"key": "2026/2026-03.zip",
16
"size": 482113,
17
"records": 3,
18
"updatedAt": "2026-04-16T08:46:34.557Z"
19
}
20
]
21
}
Download Entire Dataset: https://api.sec-api.io/datasets/form-sbsef-files.zip?token=YOUR_API_KEY
Downloads the complete dataset as a single ZIP archive containing every monthly container. Best suited for one-time bulk loads or full local mirrors. This endpoint requires a valid SEC API key passed via the token query parameter.
Download Single Container: https://api.sec-api.io/datasets/form-sbsef-files/2026/2026-03.zip?token=YOUR_API_KEY
Downloads one monthly container ZIP, such as the March 2026 archive shown above. Use the downloadUrl values returned by the index API to retrieve specific months on demand. This endpoint requires a valid SEC API key.
The dataset covers two EDGAR form types: SBSEF, the initial application for registration as a security-based swap execution facility, and SBSEF/A, amendments to a previously filed SBSEF application. No other form types appear in the dataset, and ongoing post-registration filings such as rule self-certifications, CCO reports, or Form 19b-4 rule changes are out of scope.
One record is one EDGAR accession — a single submission of Form SBSEF or Form SBSEF/A — materialized on disk as a folder named by the 18-digit dashless accession number. The folder bundles the metadata.json submission summary, the structured primary_doc.xml form body, an xslSBSEF_X01/ XHTML rendering, and any exhibit attachments (predominantly PDFs) included with that submission.
The filer is always the security-based swap execution facility itself — the legal entity (typically a Delaware-domiciled LLC or Inc.) that operates the multilateral trading platform on which security-based swaps are traded. Section 3D of the Exchange Act and Rule 803 make registration a precondition to lawful operation. Parent holding companies, dealer participants, officers, and named service providers are not filers of Form SBSEF.
The dataset's earliestSampleDate is 2024-08-01. Form SBSEF entered service on EDGAR as a born-digital, XML-native form in August 2024 — the first month after Regulation SE compliance dates took effect — and the dataset covers every Form SBSEF and Form SBSEF/A filing from that point onward, refreshed as new filings are accepted.
Form SEF is the CFTC analogue for swap execution facilities trading non-security-based swaps, filed with the CFTC under CEA Section 5h and not present on EDGAR. Form SBSEF is filed with the SEC under Exchange Act Section 3D and covers security-based swaps (single-name and narrow-index credit and equity SBS). Many entities operate dual-registered venues and must file both forms separately; only the SEC side appears in this dataset, and SBSEF registrants are assigned SEC file numbers in the dedicated 039-100xxx range.
Records combine three file types: JSON (the metadata.json submission summary), XML (the primary_doc.xml structured form body and the XHTML rendering under xslSBSEF_X01/), and PDF (the exhibit attachments — rulebooks, compliance manuals, financial-resources statements, governance schedules). The dataset is delivered as monthly ZIP containers.
The XML cover page is a thin skeleton; the substantive content lives in the attached exhibits. Exhibit M (the rulebook) and Exhibit O (compliance manual and written supervisory procedures) are typically the largest and most frequently amended, with Exhibit I (financial resources), Exhibit L (Core Principle compliance mapping), Exhibit N (third-party service agreements), and the officer/governance exhibits (A, B, C) also carrying analytic weight. Meaningful analysis aggregates each applicant's chain of SBSEF and SBSEF/A accessions rather than treating each accession in isolation.