Storage and Retrieval of 

Swap Data Repository Data

CFTC Technology Advisory Subcommittee On 

Data Standards Working Group

 

12/13/2011
2

Objectives

• Establish a common language for describing SDR functionality

– Well defined terms should enable market participants to discuss functionality without

confusion

– Abstract description of functionality will enable SDRs to build to a common ideal

• Provide a set of recommendations about where standardization of data formats, protocols

for retrieval, and data storage should be or could be applied

• Beginning to think about implementation and phasing timeline

12/13/2011
3

Main Sections

• Source data for cleared and uncleared swaps

• Observations on the need for standard SDR storage methods

• General principles for enabling the public and private retrieval of data

• Ideas on an implementation timeline

• Glossary – a common language

12/13/2011
4

Recommendation 1 – Data formats

• Leverage existing standards and allow for differences in formats at the start, so that

reporting is done in the format that best represents the particular product, market

conventions and protocols and gets as much data into the SDR’s as quickly as possible.

• OTC and traditional exchange traded/cleared swaps often have different data structures

and different protocols.

• Standard Formats for data already exist.

– FIXML for exchange traded/cleared Some clearinghouses have adopted FpML.

– FpML is used for most OTC products.

• Where an entity is already reporting to the regulators in a form that meets the

requirements of the rule it would not be cost effective to force them to migrate to a new

standard as no new information would be provided and new costs would be incurred.

12/13/2011
5

Recommendation 1 – Open Issues

• What is the best way to combine the OTC and Cleared worlds into a common format to

support both, and support movement of products (such as a formerly uncleared swap

becoming a cleared swap)?

• A large portion of the market has agreed to adopt FpML, but a significant piece already

uses FiXML. How do we balance the benefits of uniformity with the costs that would be

imposed on FiXML users if they were to be forced to convert to FpML?

12/13/2011
6

Recommendation 2 - Storage

• The native format of a transaction should be the format that the data existed in at the time

of submission to the SDR.

• Data will have to be stored and maintained for a very long time.

– CFTC is proposing a five year retention beyond the duration of the swap. Thus, a 50

year swap would need to be maintained for 55 years.

– Technology will change over the life of the transaction and this may have implications

for the ability to preserve original records.

• Data storage methods should not be mandated to a particular technology as each SDR will

need the flexibility to select the best solutions to support their current needs and to adapt

over time as needs change.

– This is not a problem as long as output is standardized.

12/13/2011
7

Recommendation 3 – Versions for Product IDS

• Rather than allow every minor change to a product definition to result in a new and distinct

product ID, keep product IDs stable by associating a version with product IDs. It will be

important to match the product ID AND the version, particularly when contract lifetimes are

long compared to the duration of a given version.

• At first glance this would seem to be in conflict with working group 2 which has

recommended an immutable UPI.

• The two ideas may be reconciled by assuming that the recommended UPI scheme is

version 1. This proposal simply leaves room for the industry to evolve over time. 

12/13/2011
8

Recommendation 4 - Time Line

• Implementation of the full SDR framework is a very complex process and will need to be

done in phases

• For each type of function SDR’s will need a test period and a go live date

• There are at least 6 separate milestones that may have different dates. In order:

– Insure that SDR requirements are international and applied consistently to avoid

regulatory arbitrage.

– Begin reporting of non-cleared trades.

– Begin dissemination of public data on a real-time basis

– Require the reporting of cleared trades into SDR’s.

– Provide query functionality to regulators

– Provide more complex portfolio analytics to regulators

12/13/2011
9

Recommendation 4 – Time Line Considerations

• In setting the dates for this timeline the regulators will need to balance the need for asset

class completeness with desire to get the greatest number of trades reported

• It will be easier for the industry to agree on how to report simple trades for each asset

class. This will give the greatest number of trades but will lengthen the time until full

analysis of a given market segment is possible.

12/13/2011
10

Glossary

• In addition to the recommendations we have provided a glossary of terms.

• With all of the new actors and processes that are being implemented it is necessary for

market participants to develop a common language

• We have provided a list of defined terms that we have used and that we hope will form the

basis for an industry wide effort.

12/13/2011