The Form SDR Files Dataset is a normalized collection of every EDGAR submission of Form SDR and Form SDR/A — the SEC's application, amendment, and withdrawal filing for security-based swap data repositories (SBSDRs). Each record is one complete EDGAR submission identified by its 18-digit accession number, bundling the EDGAR submission metadata, the structured XML application body, the XHTML rendering EDGAR produces through its SDR_X01 XSL stylesheet, and any supplemental documents (most commonly CORRESP correspondence such as withdrawal letters). Filings are made by SBSDR legal entities registering under Section 13(n) of the Securities Exchange Act and Rules 13n-1 and 13n-2 — the same submission also serves as the applicant's application for registration as a securities information processor (SIP) under Section 11A. The dataset covers filings from April 2016, when EDGAR began accepting Form SDR, to the present, delivered as ZIP containers partitioned by calendar month and populated with XML, HTML, and JSON files.
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 reproduces the registrant-filed Form SDR and Form SDR/A package as it was received by EDGAR. Form SDR is the SEC's application for registration, amendment of registration, or withdrawal from registration as a security-based swap data repository, filed pursuant to Section 13(n) of the Securities Exchange Act of 1934 and Rules 13n-1 and 13n-2 thereunder. Because the same filing simultaneously functions as the applicant's application for registration as a securities information processor under Section 11A of the Exchange Act, one Form SDR submission carries the SBSDR and SIP applications jointly. The form bears OMB control number 3235-0719 and is assigned EDGAR file numbers in the 040- block reserved for SBSDR registrations (for example, 040-00619 and 040-00621).
The dataset contains two submission types:
SDR — initial application for registration.SDR/A — amendment. Amendments serve two regulatory purposes under Rule 13n-1: (a) prompt amendments triggered whenever previously reported information ceases to be accurate or complete, and (b) the annual amendment due within 60 days of each fiscal year end. Withdrawal-of-registration filings are also submitted as SDR/A; their body marks the relevant item as a "withdrawal letter" or "APPLICATION WITHDRAWAL LETTER" and the substantive correspondence is attached as a CORRESP exhibit.Everything needed to reconstruct the application — including EDGAR's per-document SGML envelopes around exhibits — is preserved inside the accession folder; only image assets referenced by the rendered XHTML are omitted. The dataset spans filings from April 2016 onward and is distributed as ZIP containers partitioned by calendar month, containing XML, HTML, and JSON files.
A single record is one complete EDGAR submission of Form SDR or Form SDR/A by a security-based swap data repository, identified by its 18-digit EDGAR accession number. The record bundles, for that accession:
primary_doc.xml),SDR_X01 XSL stylesheet, andCORRESP correspondence such as withdrawal letters).Records are delivered as ZIP containers partitioned by calendar period; each archive expands into a YYYY/YYYY-MM/ folder hierarchy. Inside the month folder, each filing is a child directory whose name is the 18-digit, zero-padded EDGAR accession number with no dashes (for example 000165849618000003). The 18 digits decompose into the filer CIK (10 digits, zero-padded), the two-digit filing year, and a six-digit per-filer sequence; the dashed canonical form (0001658496-18-000003) appears inside metadata.json. Because the registered SBSDR population is very small, most monthly folders contain only a handful of accession directories, and many months contain none.
Every accession folder is built around the same skeleton:
metadata.json — the per-filing index that catalogs every document in the submission.primary_doc.xml — the structured Form SDR body (XML).xslSDR_X01/primary_doc.xml — the XHTML rendering of that same body, produced by EDGAR's SDR_X01 XSL stylesheet.filename2.htm, filename3.htm, …) carrying supplemental documents, each wrapped in EDGAR's SGML envelope.The file-types found in the dataset are XML (the structured form body and the XSL-rendered XHTML, both served with .xml extensions), HTML (exhibit documents wrapped in SGML, served with .htm), and JSON (the per-filing metadata index). Image files referenced by the rendered XHTML — the radio-button and checkbox glyphs under /Images/ and the EDGAR print stylesheet at /css/SDR_print.css — are not redistributed inside the record; the XHTML links to them at their canonical SEC web paths.
metadata.json indexmetadata.json is the entry point to the record and the index for every other artifact in the accession folder. Its keys describe the submission at the EDGAR envelope level and enumerate every document the filer attached.
Submission identification
formType — SDR or SDR/A.accessionNo — dashed accession (NNNNNNNNNN-YY-NNNNNN).description — human-readable filing description, e.g. Form SDR/A - Security-Based Swap Data Repository Registration: [Amend].filedAt — ISO-8601 timestamp with timezone offset (e.g. 2018-03-27T13:12:20-04:00), recording EDGAR acceptance time.id — opaque dataset record identifier (hex string).EDGAR back-links
linkToFilingDetails — URL to the XSL-rendered XHTML primary document on EDGAR.linkToTxt — URL to the complete-submission .txt SGML bundle for the accession.linkToHtml — URL to the EDGAR filing-index page.linkToXbrl — present but always empty for Form SDR.dataFiles — present but always empty for Form SDR.seriesAndClassesContractsInformation — present but always empty (an investment-company-series construct that does not apply to SBSDRs).documentFormatFiles array — enumerates every document EDGAR received. Each entry carries sequence, size (bytes, as string), documentUrl, and type. The conventional pattern is:
sequence: "1" and type equal to the form type (SDR or SDR/A) — one pointing to the XSL-rendered XHTML at xslSDR_X01/primary_doc.xml, the other to the source primary_doc.xml;sequence 2 and higher and type set to the exhibit class (CORRESP is the dominant class);sequence and blank type, with description: "Complete submission text file", pointing at the .txt SGML bundle on EDGAR.The type value is the authoritative classifier for which document is the form body, which are exhibits, and which is the SGML bundle.
entities array — identifies each filer associated with the accession. For Form SDR this is typically the applicant SBSDR alone, with companyName carrying the role suffix (Filer). Per-entity fields include cik (10-digit zero-padded), fileNo (the 040- SBSDR file number), irsNo (EIN without dashes), stateOfIncorporation (two-letter code), fiscalYearEnd (MMDD), act (34, the Securities Exchange Act), type (form type), and filmNo (EDGAR film number).
primary_doc.xml form bodyprimary_doc.xml carries the structured Form SDR application. Its root element is <edgarSubmission> under the namespace http://www.sec.gov/edgar/sdrfiler, and its content divides into two top-level halves: <headerData> and <formData>.
<headerData> — EDGAR submission envelopeThis block holds submission metadata that is not part of the public Form SDR text but is required by the EDGAR filer system.
submissionType — SDR or SDR/A.filerInfo.filer.filerCredentials — cik and a redacted ccc access code.filerInfo.flags — boolean controls including returnCopyFlag, overrideInternetFlag, and confirmingCopyFlag.filerInfo.contact — the submission contact's name, phone, and email.filerInfo.liveTestFlag — LIVE for production filings or TEST for filer tests.<formData> — the Form SDR application<formData> mirrors the printed Form SDR, reproducing its identification block, numbered Items 1 through 11, and the signature block. A defining structural feature is that almost every substantive field is paired with a sibling *ConfFlag element carrying the per-field confidentiality request (see the confidentiality subsection below).
principalInfo — applicant identification: applicantName, street, city, stateOrCountry, zipCode. For amendments, amendedItemsList is a free-text enumeration of which Items are being amended; for withdrawal filings it carries language such as "withdrawal letter" or "APPLICATION WITHDRAWAL LETTER". prncpalConfFlag marks confidentiality on the principal-info block.generalInfo.business — alternate business name and previous business name fields plus a businessAddress, each with its own *ConfFlag.generalInfo.officeInfo.office — the principal office at which SBSDR / SIP activities are conducted, with officeName, address, state, and zip.generalInfo.successor — boolean indicators describing whether the applicant is a successor to a previously registered SBSDR: successionFlag, successionDateFlag, predecessorNameAddressFlag, predecessorCikFlag.generalInfo.assetClasses.assetClassesList — free-text enumeration of the asset classes of security-based swaps the applicant collects or proposes to collect (e.g. "Credit, Equity and Rates", or a longer descriptive sentence for a narrower scope).generalInfo.functionDescription.functionDescriptionPerformed — free-text description of the SBSDR / SIP function the applicant performs.generalInfo.applicantCategory — applicantType (Corporation, Partnership, or "Other Form of Organization") and, when applicable, applicantTypeOtherDesc (e.g. "Limited Liability Company").generalInfo.corpOrgInfo — dateOfCoperationOrg (date of incorporation, MM-DD-YYYY) and stateCorperationOrOrg (state or country of organization). Note that the schema's element names are misspelled but are used as-is.generalInfo.partnershipInfo — filing-partner indicator, populated only for partnership applicants.generalInfo.consentName / consentAddress / consentPhone — the designated officer or agent in the United States to whom the SEC may direct service of process, with that person's name, U.S. address, and phone number.signatureInfo — signatureDate (MM-DD-YYYY), signatureApplicantName, signature (signer name), and signatureTitle. The signature block carries the certification by which the signer attests to the truth and completeness of the application.The numbered Items of the printed form map onto these elements in two groups: Items 1–7 (alternate business name, previous business name, mailing address, principal office, successor information, asset classes, function description) and Items 8–11 (applicant category, date and state of incorporation, partnership filing-partner information, consent for service of process). The signature block closes the form.
xslSDR_X01/primary_doc.xml is the same Form SDR data after applying EDGAR's SDR_X01 XSL stylesheet. Despite the .xml extension, the file is XHTML intended for browser display and links to /css/SDR_print.css and to EDGAR image assets (/Images/radio-checked.jpg, /Images/box-unchecked.jpg, and related glyphs) for the radio-button and checkbox renderings. The rendered document opens with a "Form SDR Filer Information" header table identifying the SEC and printing OMB approval number 3235-0719, then proceeds through these visual blocks in order:
This rendering is what an EDGAR user sees from the filing-detail page; the dataset preserves it verbatim so that the visually authoritative version of the application remains available alongside the structured XML. Because the XHTML and the source XML carry the same sequence: "1" in documentFormatFiles, distinguishing them programmatically requires inspecting documentUrl (the XHTML lives under xslSDR_X01/).
When the filer attaches supplemental documents, each appears in the accession folder under its EDGAR-assigned filename (typically filenameN.htm where N matches the document sequence in metadata.json). The dominant exhibit class is CORRESP (correspondence with the SEC, including withdrawal letters). Although these files carry an .htm extension, their content is not free-form HTML; it is the standard EDGAR SGML document envelope wrapping the payload:
1
<DOCUMENT>
2
<TYPE>CORRESP
3
<SEQUENCE>2
4
<FILENAME>filename2.htm
5
<TEXT>
6
... payload (XML, HTML, or plain text) ...
7
</TEXT>
8
</DOCUMENT>
The five SGML tags — <DOCUMENT>, <TYPE>, <SEQUENCE>, <FILENAME>, and <TEXT> — form EDGAR's per-document framing. The payload between <TEXT> and </TEXT> may itself be an XML body (for example, a duplicate of the Form SDR submission XML), HTML markup, or plain text, depending on what the filer attached. Form SDR's exhibit ecosystem is narrower than that of operating-company forms: the form solicits its substantive disclosures (governance and operations description, asset-class coverage, function-description text, organizational details) inside the <formData> body rather than through a structured set of numbered exhibits, so correspondence-class attachments — particularly withdrawal letters — dominate the exhibit population.
A distinctive structural feature of Form SDR is the per-field confidentiality flag. Almost every named field or block in <formData> is paired with a *ConfFlag sibling (prncpalConfFlag on the principal-info block, business-name conf flags, office-info conf flags, asset-class conf flag, function-description conf flag, and so on). These flags express a per-item request that the SEC accord confidential treatment to the marked content under Rule 13n-4(b)(8) and the broader confidential-treatment framework.
The flags are an integral part of the data model rather than metadata commentary: a populated text field whose paired *ConfFlag is set indicates that the filer requested confidential treatment for that specific item, even when other items in the same submission are public. Any consumer parsing the XML body must read each flag alongside its paired value to interpret the confidentiality posture correctly. The XSL-rendered XHTML reproduces these flags as inline checkboxes next to each Item.
A record includes:
metadata.json (the per-filing index),primary_doc.xml (the structured form body),xslSDR_X01/primary_doc.xml (the XSL-rendered XHTML view), andCORRESP exhibits and any other supplemental documents) under its EDGAR-assigned filename.A record does not include:
.txt SGML bundle — referenced by linkToTxt in the metadata and retrievable from EDGAR using that URL, but not stored locally;/Images/ and the print stylesheet at /css/SDR_print.css) — references remain inside the XHTML so that, when served against the SEC's static asset paths, the rendering displays correctly.The linkToXbrl and dataFiles keys are present in metadata.json but always empty for Form SDR.
Form SDR was adopted as part of the SEC's implementation of Title VII of the Dodd-Frank Act, and the dataset spans filings from April 2016 onward. Across that window, the structured XML schema under the http://www.sec.gov/edgar/sdrfiler namespace, the <headerData> / <formData> split, the Items 1–7 / Items 8–11 / Signature partitioning of the rendered view, and the *ConfFlag confidentiality pattern have remained stable. Filings have been delivered consistently as XML body plus XSL-rendered XHTML plus SGML-wrapped exhibits since the dataset's earliest entries.
The principal source of cross-record variation is therefore not the data model but the filing type and intent: initial SDR applications carry the full descriptive content of a new registration; SDR/A amendments populate amendedItemsList with the specific Items being changed (or with withdrawal language when the amendment effects a withdrawal of registration); annual amendments use the same SDR/A form to refresh fiscal-year-affected disclosures. The registered SBSDR population is small, so cross-filer variability — in legal form, asset-class scope, and function-description prose — is correspondingly limited.
sequence: "1". documentFormatFiles carries one entry for the XSL-rendered XHTML at xslSDR_X01/primary_doc.xml and another for the source primary_doc.xml, both with sequence: "1" and type equal to the form type. Consumers selecting the form body should prefer the source XML; consumers selecting a human-readable rendering should prefer the XHTML view. The two are distinguishable only by documentUrl.accessionNo in metadata.json refer to the same accession; either can be used as a record key, but they require trivial reformatting (insert dashes after positions 10 and 12, or strip them) to interconvert.amendedItemsList free-text inside principalInfo, not in a discrete enumerated field. Withdrawal-of-registration filings appear as SDR/A submissions whose amendedItemsList mentions withdrawal language (e.g. "withdrawal letter" or "APPLICATION WITHDRAWAL LETTER") and which typically attach a CORRESP exhibit carrying the substantive withdrawal letter.*ConfFlag as an independent assertion. Aggregating to a record-level "is this filing confidential" flag will discard the granularity that the form is designed to express.040- is the reliable SBSDR filter. The 040- file-number prefix uniquely identifies SBSDR registrations and links Form SDR records to the SEC's broader SBSDR public listings.assetClassesList and functionDescriptionPerformed vary in length and style across filers and across amendments by the same filer; downstream extraction should treat them as narrative content rather than controlled vocabulary.dateOfCoperationOrg and stateCorperationOrOrg (with the Coperation/Corperation typos baked in). XPath and DOM consumers must match these literal element names.xslSDR_X01/primary_doc.xml is HTML-shaped despite its .xml extension; MIME-based parsing should rely on content inspection or on the type annotation in metadata.json rather than the filename suffix..htm files require unwrapping. Exhibit files carry the EDGAR SGML envelope around their payload; consumers must strip the <DOCUMENT> / <TYPE> / <SEQUENCE> / <FILENAME> / <TEXT> framing before parsing the payload (which may itself be XML or HTML).linkToXbrl and dataFiles keys exist for schema uniformity across the broader EDGAR dataset family and are always empty here.Each record is filed by a security-based swap data repository (SBSDR) that is registering with the SEC, amending an existing application or registration, or withdrawing. Because the same submission also serves as the entity's application for registration as a securities information processor (SIP), one Form SDR filing addresses two registration regimes simultaneously.
The filer of record is the SBSDR legal entity itself, not its parent, its officers, or its counsel. Counterparties to security-based swaps (dealers, major participants, end users) do not file Form SDR; only the repository that warehouses their transaction data does. Adjacent infrastructure registrants use different forms: broker-dealers file Form BD, exchanges Form 1, clearing agencies Form CA-1, and security-based swap execution facilities Form SBSEF.
The SBSDR universe is extremely narrow. Filers are corporate affiliates of major post-trade infrastructure groups. The visible filers in EDGAR are:
SBSDRs are assigned SEC file numbers in the 040- series, the block the Commission uses for this registrant class.
Form SDR is mostly event-driven, with one recurring periodic obligation. The form type distinguishes only between an original filing (SDR) and any amendment or withdrawal (SDR/A); the underlying trigger must be read from the submission body.
SDR). Filed when a new entity seeks SBSDR registration. The same package serves as its SIP application.SDR/A). Required promptly whenever specified information previously reported on Form SDR becomes inaccurate, whether the registration is still under review or already effective.SDR/A). Each registered SBSDR must file an amendment within 60 days after the end of each fiscal year, reaffirming or updating information of record. This is the only calendar-driven trigger and produces the recurring cadence of SDR/A filings in the dataset.SDR/A). Filed when an SBSDR ceases to be registered. Withdrawals are rare given the small, stable population.The form was created under Title VII of the Dodd-Frank Act and is anchored in:
Because Form SDR also serves as the SIP application, registration as a SIP is processed in parallel under Section 11A of the Exchange Act.
EDGAR began accepting Form SDR in April 2016, when the first SBSDR applicants filed. There is no pre-EDGAR paper legacy: the form and the SBSDR regime are both post-Dodd-Frank constructs.
Form SDR sits at the junction of three regimes that are easy to confuse: Title VII Dodd-Frank security-based swap (SBS) registrations, SEC market-infrastructure registrations, and the parallel CFTC swap data repository regime. The useful comparison set is therefore the other Title VII SBS forms, the SEC entity-registration forms for trading venues and clearing agencies, and the CFTC-side analog. Issuer filings (10-K, 8-K) and broker-dealer financial reports are not informative comparators: Form SDR is an entity-registration application for a post-trade reporting utility, not an issuer or financial-condition disclosure.
The SBSE forms register security-based swap dealers and major SBS participants under Section 15F of the Exchange Act and Rules 15Fb1-1 through 15Fb6-2. Both regimes were created by Title VII, but they cover opposite sides of the market: SBSE registers the intermediaries that transact in SBS; Form SDR registers the trade repositories that collect and maintain SBS transaction data. Key distinctions:
The two datasets are complementary, not substitutable; a full SBS-ecosystem view requires both.
Forms ATS and ATS-N register alternative trading systems operated by broker-dealers under Regulation ATS (Rules 301 and 304). Both ATS and SDR filings register a piece of market infrastructure and include detailed operational disclosure, but they describe different functions: ATSs match buyers and sellers pre-trade, while SDRs warehouse post-trade SBS transaction records. ATS filings are far more numerous, are filed by registered broker-dealers, and sit alongside the operator's 008- BD number; ATS-N in particular is a structured, machine-readable form for NMS-stock ATSs. Form SDR has no order-interaction or matching component and a much smaller filer population.
Form 1 registers national securities exchanges under Section 6 of the Exchange Act; Form 19b-4 is the vehicle by which SROs (including exchanges, clearing agencies, FINRA, the MSRB, and SDRs designated as self-regulatory organizations) file proposed rule changes under Section 19(b). Both touch the SRO layer but answer different questions:
A researcher tracking an SDR's rulebook reads its 19b-4s; one tracking changes to services, fees, governance, or system architecture reads SDR/SDR-A amendments.
CA-1 is the closest non-SBS comparator. It registers clearing agencies under Section 17A of the Exchange Act and, like Form SDR, is a low-volume entity-registration filing for regulated post-trade infrastructure with extensive narrative and exhibit disclosure on governance, financial resources, operational capacity, risk management, and system safeguards. The boundary is functional: clearing agencies act as CCPs or CSDs that intermediate settlement and bear credit risk, while SDRs are pure data repositories that receive, store, and disseminate SBS transaction reports. Statutory authority differs (Section 17A vs. Section 13(n)), and the file-number prefix differs (012- for clearing agencies vs. 040- for SDRs). The two datasets complement each other for mapping SEC-regulated post-trade infrastructure.
The CFTC's swap data repository regime under Part 49 is the direct sibling of SEC Form SDR and the single most important "not the same dataset" comparison. Title VII bifurcated swaps between the CFTC (most swaps, including interest-rate, FX, and most commodity swaps) and the SEC (security-based swaps — primarily single-name and narrow-index credit default swaps and equity swaps). CFTC SDR filings are submitted to the CFTC, do not appear on EDGAR, and are governed by CFTC Part 49 rather than SEC Rules 13n-1 through 13n-12. Content is analogous (governance, services, fees, system safeguards, access), and several entities (notably DTCC Data Repository) register with both agencies, but the filings live in separate systems. This dataset contains only the SEC-side records.
Listed only to draw the boundary. FOCUS reports are periodic, highly tabular financial-condition reports filed by registered broker-dealers under Rule 17a-5, covering net capital, customer protection, and financial responsibility. Form X-17A-5 is a narrative-and-exhibit registration application for a non-broker-dealer infrastructure entity. No substantive overlap; the two should not appear in the same comparative analysis.
Form SDR is distinguished by the combination of:
040- series, distinct from 008- (BD/exchange/SBSE), 012- (clearing agencies), and the ATS file-number series.SDR), prompt amendments when disclosed information becomes inaccurate, and a mandatory annual amendment within 60 days of fiscal year end (SDR/A), plus any withdrawal.SBSE covers the intermediary side of SBS; CFTC SDR covers the non-security-based swap repository universe; CA-1 anchors the broader SEC post-trade infrastructure comparison; and Form 1, Form ATS/ATS-N, and Form 19b-4 sit on the trading-venue and rulebook side. None substitute for Form SDR when the question concerns the registration, ongoing disclosure, or amendment history of SEC-regulated security-based swap data repositories.
The record count is small, but each Form SDR filing carries dense, consequential disclosure. Users cluster in a few specialized roles.
Map the SBSDR landscape over time: who is registered, who has amended, who has withdrawn, and which asset classes (credit, equity, interest rate) each repository covers. Key fields: formData/principalInfo, repository function descriptions, asset-class scope items, and the SDR/A amendment chronology. Output: landscape notes and routing advisory memos.
In-house compliance officers and general counsel at registered or applicant repositories benchmark their own disclosures against peers when drafting the annual 60-day post-fiscal-year amendment or a triggered amendment for inaccurate information. They compare governance exhibits, conflict-of-interest policies, fair-access provisions, CCO mandates, and system-safeguard narratives.
Reporting teams at swap dealers, SBS dealers, major SBS participants, and large buy-side firms depend on SBSDRs to ingest Regulation SBSR reports. They use the dataset to verify current registration status, watch for SDR/A filings that change covered asset classes or technical scope, and catch CORRESP withdrawal letters that force re-routing of reporting flows.
Outside counsel preparing SDR applications, amendments, or withdrawal letters use prior filings as a precedent library. Workflows: precedent searches before a new filing, redlines across SDR/A versions to see what staff pushed back on, and modeling exit filings on prior CORRESP withdrawal letters. Focus on function descriptions, board and CCO governance exhibits, recordkeeping policies, and fee schedules.
Counterparty risk and middle-office teams confirm that the repository handling their or their counterparties' SBS reports is currently registered. They pull the registered legal entity, principals in formData/principalInfo, asset-class coverage, and the date of the most recent amendment to feed onboarding files, vendor risk assessments, and control attestations.
Academic and policy researchers studying Section 763 implementation and post-2008 derivatives transparency build empirical records of SBSDR registration from 2016 onward. They use filing dates, registrant identities, asset-class scope, amendment frequency, and the substantive narratives in function and governance exhibits to support working papers and regulatory comment letters.
Engineers building regulatory knowledge graphs and retrieval systems for derivatives compliance ingest the XML/JSON formData, exhibit lists, principal information, and amendment metadata to maintain a live registry of SBSDR status and to ground LLM answers about who is authorized to receive SBS reports.
Value lies in completeness, not volume: the dataset is the public registration record for a regulated infrastructure category with very few participants and high consequences whenever one of them files, amends, or withdraws.
The use cases below describe concrete workflows that exploit specific record fields.
A regulatory-reporting engineer at a swap dealer ingests every accession's metadata.json (formType, filedAt, entities[].cik, entities[].fileNo) plus formData/principalInfo/applicantName and formData/generalInfo/assetClasses/assetClassesList from primary_doc.xml. The output is a registry table — keyed on the 040- file number — that maps each SBSDR to its current legal name, registration status, and covered asset classes (credit, equity, rates), used to route Regulation SBSR reports to authorized repositories.
A buy-side compliance team monitors new accession folders for formType: SDR/A whose principalInfo/amendedItemsList contains "withdrawal letter" or "APPLICATION WITHDRAWAL LETTER" and whose documentFormatFiles includes a CORRESP exhibit. The workflow strips the EDGAR SGML envelope from the filenameN.htm payload, extracts the effective withdrawal date, and triggers an internal ticket to redirect SBS transaction reporting before the withdrawal date arrives.
A general counsel at a registered SBSDR preparing the Rule 13n-1 annual amendment (due 60 days after fiscal year end) pulls every prior SDR/A filed by other registrants and diffs functionDescriptionPerformed, assetClassesList, consentName/consentAddress/consentPhone, and generalInfo/officeInfo/office across submissions. Output: a peer-benchmark redline used to scope disclosure changes and to calibrate the wording of the function-description narrative.
A market-structure analyst parses every *ConfFlag element in primary_doc.xml (prncpalConfFlag, business-name flags, office-info flags, assetClassesList flag, functionDescriptionPerformed flag, and the per-block flags throughout generalInfo) and aggregates by registrant and filing date. Output: a longitudinal table showing which Form SDR items each repository requests confidential treatment for under Rule 13n-4(b)(8), used to characterize disclosure norms in the SBSDR segment.
An outside attorney drafting a new SBSDR application or a substantive amendment indexes every primary_doc.xml body plus every CORRESP exhibit payload across all filings, segmented by formType (SDR versus SDR/A) and by amendedItemsList text. The result is a searchable precedent library — keyed on Items 1 through 11 and on amendment scope strings — that supports clause-level reuse, SEC-staff feedback patterns inferred from amendment sequences, and modeling of exit filings on prior withdrawal letters.
A data-engineering team ingests metadata.json, the XSL-rendered xslSDR_X01/primary_doc.xml, and the unwrapped exhibit payloads into a retrieval index. The RAG system answers questions such as "which repositories are currently authorized for equity SBS reporting?" or "what was the latest function description filed by [registrant]?" by retrieving from assetClassesList, functionDescriptionPerformed, signatureDate, and the chronologically last non-withdrawal SDR/A per cik.
A policy researcher studying Dodd-Frank Title VII implementation builds an event panel from filedAt, entities[].cik, formType, applicantType, dateOfCoperationOrg, and stateCorperationOrOrg across all accessions since April 2016. Output: a working-paper dataset of SBSDR entry, amendment cadence, and exit, used to characterize the pace and concentration of SBSDR registration over the decade after the 2010 Act.
The Form SDR Files dataset is available through three access patterns: a metadata index endpoint, a full dataset archive download, and per-container downloads. Containers are organized by year and month, packaged as ZIP archives, and include XML, HTML, and JSON files for each filing.
Dataset Index JSON API: https://api.sec-api.io/datasets/form-sdr-files.json
This endpoint returns dataset-level metadata (name, description, earliest sample date of 2016-04-01, last updated timestamp, total records, total size, covered form types SDR and SDR/A, container format, and file types) along with the full list of container files. Each container entry includes its key, size, record count, last updated timestamp, and direct download URL. Use this endpoint to track which containers were modified in the most recent refresh and decide which to re-download. No API key is required to call this endpoint.
Example response:
1
{
2
"datasetId": "1f13365b-9ae0-6a81-bbce-f44f70308757",
3
"datasetDownloadUrl": "https://api.sec-api.io/datasets/form-sdr-files.zip",
4
"name": "Form SDR Files Dataset",
5
"updatedAt": "2026-05-11T02:51:19.000Z",
6
"earliestSampleDate": "2016-04-01",
7
"totalRecords": 121,
8
"totalSize": 1039875,
9
"formTypes": ["SDR", "SDR/A"],
10
"containerFormat": "ZIP",
11
"fileTypes": ["XML", "HTML", "JSON"],
12
"containers": [
13
{
14
"downloadUrl": "https://api.sec-api.io/datasets/form-sdr-files/2026/2026-03.zip",
15
"key": "2026/2026-03.zip",
16
"size": 18452,
17
"records": 2,
18
"updatedAt": "2026-03-21T02:51:19.000Z"
19
}
20
]
21
}
Download Entire Dataset: https://api.sec-api.io/datasets/form-sdr-files.zip?token=YOUR_API_KEY
Downloads the complete dataset as a single ZIP archive containing all monthly containers. This endpoint requires authentication via your SEC API key passed as the token query parameter.
Download Single Container: https://api.sec-api.io/datasets/form-sdr-files/2026/2026-03.zip?token=YOUR_API_KEY
Fetches one individual monthly container. Replace the year/month path segment with any containers[].key value returned by the index API to download a specific archive. This endpoint also requires authentication via your SEC API key.
The dataset covers SEC Form SDR and its amendment variant Form SDR/A — the application, amendment, and withdrawal filing for security-based swap data repositories (SBSDRs) under Section 13(n) of the Securities Exchange Act of 1934 and Rules 13n-1 and 13n-2. The same submission also serves as the applicant's application for registration as a securities information processor (SIP) under Section 11A.
One record is one complete EDGAR submission of Form SDR or Form SDR/A, identified by its 18-digit accession number. The record bundles the EDGAR submission metadata (metadata.json), the structured XML application body (primary_doc.xml), the XSL-rendered XHTML view (xslSDR_X01/primary_doc.xml), and any attached exhibits — most commonly CORRESP correspondence such as withdrawal letters.
The filer of record is the SBSDR legal entity itself — not its parent, its officers, or its counsel. Counterparties to security-based swaps do not file Form SDR; only the repository that warehouses their transaction data does. In practice, the visible filer population is very narrow and includes affiliates of major post-trade infrastructure groups such as DTCC Data Repository (U.S.) LLC and ICE Trade Vault, LLC.
SDR is filed when a new entity seeks SBSDR registration. SDR/A is filed promptly whenever previously reported information becomes inaccurate, within 60 days after the end of each fiscal year as a mandatory annual amendment, and when an SBSDR withdraws from registration. The form type alone does not distinguish among prompt, annual, and withdrawal amendments — the trigger must be read from the amendedItemsList text inside primary_doc.xml.
The dataset spans filings from April 2016, when EDGAR began accepting Form SDR, to the present. There is no pre-EDGAR paper legacy: both the form and the SBSDR registration regime are post-Dodd-Frank constructs created under Title VII.
The dataset is delivered as ZIP containers partitioned by calendar month, with each archive expanding into a YYYY/YYYY-MM/ folder hierarchy. Inside each accession folder, files are XML (the structured form body and the XSL-rendered XHTML, both with .xml extensions), HTML (exhibit documents wrapped in EDGAR's SGML envelope, with .htm extensions), and JSON (the per-filing metadata.json index).
The CFTC separately registers SDRs for non-security-based swaps under Section 21 of the Commodity Exchange Act and CFTC Part 49. Those filings are submitted to the CFTC, do not appear on EDGAR, and are not included in this dataset, even when the same corporate group (such as DTCC Data Repository) registers with both agencies. This dataset contains only the SEC-side Form SDR and Form SDR/A submissions made under Section 13(n) and Rules 13n-1 / 13n-2.