Swap Data Repository (SDR)

A swap data repository (SDR) is regulated market infrastructure that receives, validates, maintains, and provides access to required swap transaction data. In the United States, SDRs register with the Commodity Futures Trading Commission (CFTC) and support regulatory reporting, recordkeeping, and public dissemination under applicable CFTC rules.

An SDR does not execute, price, clear, guarantee, or settle the swap merely because it receives a report. It records the transaction data submitted under the reporting framework.

Key Takeaways

• SDRs provide regulators with transaction-level data that was difficult to observe before mandatory swap reporting.
• Required records can include creation data, counterparty information, economic terms, valuation data, and lifecycle events.
• The reporting duty depends on product classification, counterparties, execution venue, clearing status, jurisdiction, and the applicable reporting hierarchy.
• A venue, counterparty, or service provider may submit a report, but delegation does not necessarily transfer legal responsibility.
• Regulatory data and publicly disseminated data are not the same dataset.
• Public records generally omit counterparty identities and can apply delays or notional caps under the governing rules.
• An SDR validation acceptance message shows that a submission passed specified format or validation checks; it does not prove that every economic fact is correct.
• Corrections, terminations, allocations, novations, and other lifecycle events must be linked to the correct transaction record.
• CFTC SDRs and SEC security-based swap data repositories operate under related but distinct legal regimes.
• SDR data can support market analysis, but duplicates, cancellations, capped notionals, timing, and product conventions must be handled carefully.

What an SDR Does

An SDR’s core functions can include:

• accepting required swap data from authorized submitters;
• applying data-format and validation procedures;
• recording creation and continuation data;
• preserving transaction histories and corrections;
• making data available to the CFTC and other authorized regulators under applicable access rules;
• publicly disseminating reportable transaction and pricing data; and
• maintaining systems, governance, confidentiality, and compliance controls required by its regulatory framework.

The exact duties come from law, regulation, registration conditions, and the repository’s approved rules. The label SDR should not be used for an unregulated internal trade database.

Parts 43, 45, and 49 Serve Different Purposes

Within the CFTC framework, three rule areas are commonly encountered together but should not be treated as interchangeable.

A field can be required for confidential regulatory reporting under Part 45 without appearing in a Part 43 public record. Conversely, a public dissemination message is not a complete representation of every field regulators can access. The applicable regulation, technical specification, and SDR rules determine the precise treatment.

Data Reported Across the Swap Lifecycle

Swap reporting is not limited to a one-time trade ticket. A reportable record can change throughout the transaction lifecycle.

The applicable CFTC technical specifications and data-element definitions determine what must be submitted. An analyst should not infer a field’s meaning from its label alone.

Common Identifiers and Economic Fields

A regulatory swap record may use standardized identifiers and classifications, including:

• unique transaction identifiers for linking reports and lifecycle events;
• legal entity identifiers for relevant parties;
• product identifiers or product taxonomies;
• asset class and product type;
• execution, effective, and maturity timestamps;
• notional amount, notional currency, and notional schedule;
• fixed rate, floating reference, spread, price, or other economic terms;
• package, block, allocation, clearing, and platform indicators; and
• action and event types showing whether a message creates, modifies, corrects, or terminates a record.

Not every field is public. Counterparty identities, confidential business information, collateral details, and other regulatory data can be restricted even when a subset of transaction and pricing data is disseminated.

UTI, UPI, and LEI Are Not Substitutes

An analyst cannot replace one identifier with another. Two swaps can share a UPI but require different UTIs, while one lifecycle event can involve several UTIs connected by a prior UTI or event identifier. LEIs identify legal entities, not the economic product or trade.

Who Reports a Swap?

There is no reliable answer based only on the statement that two parties entered a swap. Under the U.S. CFTC framework, the required submitter can depend on whether the transaction was executed on a swap execution facility or designated contract market, whether it was cleared, the regulatory status of each counterparty, and the type of data being reported.

Possible submitters include:

• a swap execution facility;
• a designated contract market;
• a derivatives clearing organization for specified data;
• the reporting counterparty determined under the applicable hierarchy; or
• an authorized agent or service provider acting for a party.

A firm can use a third party to facilitate reporting while retaining responsibility imposed by the rule. The correct analysis identifies the exact rule, report type, reporting side, submission route, and deadline.

Worked Example: From Execution to Termination

Assume a U.S. company and a swap dealer enter a five-year USD pay-fixed interest rate swap with USD 25 million notional.

At execution, a report can identify the transaction, product, timestamps, notional, fixed rate, floating reference, maturity, counterparties, execution method, and clearing information. The SDR validates the message against its submission rules and records the accepted data.

For public dissemination, a reportable subset may show transaction and pricing information without naming the counterparties. A large trade may be subject to a public notional cap or dissemination delay under the applicable rule.

If the parties later reduce the notional to USD 15 million, the responsible submitter reports the lifecycle event using the identifiers and action type required to connect it to the original transaction. If the swap is then fully terminated, another report updates its status.

The sequence matters. Treating each message as a new independent swap could overstate trading volume and outstanding notional.

Lifecycle Example: Why Message Counts Mislead

Assume the original USD 25 million swap is assigned UTI-A. The following table is illustrative; exact report fields and allowable action-event combinations depend on the applicable technical specification.

Adding the six displayed notionals gives USD 100 million, but that number is neither original execution volume nor peak outstanding exposure. The original trade was USD 25 million. After the partial novation, the two open records still total USD 25 million before both are terminated.

For transaction-volume analysis, classify each message by action and event, remove or supersede corrections as required, and avoid counting lifecycle replacements as unrelated new risk. For open-interest analysis, reconstruct the latest valid state of each transaction rather than adding historical rows.

Public Data vs. Confidential Regulatory Data

Public anonymity is central. An SDR public feed should not be described as a directory of which firms hold particular positions.

Execution Time Is Not Dissemination Time

A public record can contain several timestamps with different meanings. Execution time describes when the transaction occurred. Event time describes when a lifecycle change took effect. Reporting time and dissemination time describe later data-processing steps. Delayed dissemination rules, corrections, and operational processing can make these times differ.

Analysts should preserve the original time zone and timestamp precision, then document any conversion. Sorting only by publication time can place a correction or delayed block transaction in the wrong economic sequence.

Validation, Verification, and Correction

These steps should not be confused:

• Validation checks whether a report satisfies specified data, format, allowable-value, and logical rules.
• Verification is the reporting party’s process for confirming that SDR data is complete and accurate as required.
• Correction changes an erroneous or incomplete report using the required action and linkage.
• Reconciliation compares records across counterparties, repositories, internal systems, or regulators to find differences.

A syntactically valid record can still contain the wrong notional, timestamp, counterparty, product identifier, or lifecycle action. Data governance must connect front-office, confirmation, clearing, collateral, settlement, and reporting records.

What SDR Acceptance Does and Does Not Establish

Evidence of accurate reporting therefore includes the source trade record, transformation logic, submission payload, SDR response, reconciliation result, and any correction history. One acceptance message is only one part of that evidence chain.

SDR vs. Other Swap Infrastructure

A transaction can be executed on one venue, cleared through another organization, reported to an SDR, and maintained in each counterparty’s internal systems.

CFTC SDRs vs. SEC SBSDRs

U.S. law divides regulatory responsibility between swaps overseen by the CFTC and security-based swaps overseen by the Securities and Exchange Commission (SEC).

The CFTC uses the term swap data repository. The SEC uses security-based swap data repository (SBSDR) under Regulation SBSR and related repository rules. A repository can hold registrations under both regimes, but that does not merge the legal requirements.

Outside the United States, similar infrastructure may be called a trade repository. Reporting fields, responsible parties, deadlines, public dissemination, identifiers, and access rules differ by jurisdiction.

Product classification is the first boundary check. A broad-based index swap can fall within the CFTC swap regime while a swap based on a single security or narrow-based security index may fall within the SEC security-based swap regime. Mixed or unusual products require transaction-specific legal classification rather than inference from the word swap alone.

How SDR Data Supports Analysis

SDR data can help analysts examine:

• executed prices and rates;
• transaction counts and notional volumes;
• maturity and currency distributions;
• cleared and uncleared activity;
• product and participant categories in aggregated reports; and
• changes in market activity over time.

Raw messages are not immediately equivalent to economic risk. A new trade, allocation, correction, compression replacement, and termination can each generate records. Gross notional is also different from market value, current exposure, or stress loss.

A Reproducible SDR Analysis Workflow

1. Save the source files, download times, schema version, and repository or regulator provenance.
2. Parse timestamps, currencies, identifiers, action types, and event types without silently coercing invalid values.
3. Separate public dissemination records from confidential or aggregated regulatory datasets.
4. Build an event history for each UTI and preserve links through prior UTIs and event identifiers.
5. Apply documented correction, cancellation, termination, allocation, clearing, and compression logic.
6. Create separate measures for execution activity, latest open state, gross notional, and price observations.
7. Flag capped, masked, delayed, package, and incomplete records rather than treating them as ordinary observations.
8. Reconcile selected results to regulator totals or repository controls where comparable data exist.
9. Record exclusions, transformations, unresolved errors, and version changes so another analyst can reproduce the result.

Changing a filter or lifecycle rule can materially change the output. A published chart should state whether it measures raw messages, presumed new transactions, latest open records, or another defined population.

Data Quality Risks and Common Mistakes

• Counting messages as trades: Lifecycle and correction messages can inflate activity if not classified.
• Adding capped notionals as exact amounts: Public cap values can understate the size of large trades.
• Ignoring dissemination delays: Publication time can differ from execution time.
• Assuming public data are complete regulatory records: Confidential fields are excluded.
• Treating validation as proof: Passing technical checks does not establish economic accuracy.
• Joining the wrong identifiers: Broken transaction linkage can duplicate or orphan events.
• Mixing asset classes or regimes: CFTC swaps, SEC security-based swaps, futures, and foreign reports follow different rules.
• Equating notional with risk: Notional is a scale measure, not market value or maximum loss.
• Ignoring package transactions: Individual components may not represent standalone economics.
• Overlooking cancellations and corrections: Superseded records should not remain in the analytical population.
• Mixing flow and stock measures: Execution volume during a period and open notional at a point in time answer different questions.
• Losing lineage: Dropping prior UTI or event links can make novations, clearing, allocations, and compression look like unrelated trades.
• Using the wrong schema version: Meanings, allowable values, validation rules, and required fields can change between technical specifications.
• Sorting by one timestamp: Execution, event, reporting, and dissemination times can differ.

How to Review an SDR Record

1. Identify the regulator, reporting regime, repository, and technical-specification version.
2. Determine whether the message is a new trade, lifecycle event, correction, cancellation, or termination.
3. Check transaction, product, and legal-entity identifiers.
4. Confirm execution, effective, maturity, reporting, and dissemination timestamps separately.
5. Reconcile notional, currency, price, rate, spread, and product terms with the confirmation.
6. Determine whether the public notional is capped or the report was delayed.
7. Trace allocations, clearing, novations, compressions, and amendments to the original record.
8. Exclude superseded or canceled records according to a documented method.
9. Reconcile repository data with venue, clearing, counterparty, and internal books.
10. Preserve an audit trail for corrections and analytical transformations.

Authoritative Sources

• CFTC: Data Repositories
• CFTC: Swaps Report Data Dictionary
• CFTC: Parts 43 and 45 Technical Specification
• CFTC: Data Recordkeeping Rules and Materials
• CFTC: Real-Time Reporting Rules and Materials
• CFTC: Swap Data Reporting and Recordkeeping Requirements
• CFTC: Real-Time Public Reporting Requirements
• SEC: Security-Based Swap Markets
• SEC: Security-Based Swap Data Repositories
• SEC: Regulation SBSR Frequently Asked Questions

Related Terms

• Swap: The derivative transaction whose creation and lifecycle data may be reportable.
• ISDA: The industry association that publishes derivatives documentation and operational standards.
• Notional Value: A transaction scale measure commonly included in swap reports.
• Clearing House: Infrastructure that clears eligible derivatives rather than serving as their regulatory data repository.
• Market Transparency: Availability of information that supports price discovery and oversight.
• Derivative: The broader class of contracts that includes swaps and security-based swaps.

FAQs

Check Your Understanding

This article is educational and does not provide legal, regulatory, reporting, data-governance, or trading advice. Reporting obligations and technical specifications change and must be confirmed for the transaction, parties, jurisdiction, and reporting date.