record-keeping-icon

Dodd Frank Recordkeeping rules summary

Recordkeeping rules are part of Dodd-Frank Wall Street Reform and Consumer Protection Act, specifically Title VII – Wall Street Transparency and Accountability. These rules are mandatory for Swap Dealers (SD) and Major Swap Participants (MSP). While there are several separate recordkeeping rules, all of them are inter-related and listed below.

  • CFR Part 23.201 identifies what type of records each SD and MSP must maintain. Example of records includes swap transaction information, corporate governance, financial records, complaints, and marketing and sales materials.
  • CFR Part 23.202 further identifies daily trading records for swaps and related cash and forwards. These records represent pre trade execution, trade execution and post trade execution events.
  • CFR Part 23.203 explicitly defines record retention and retrievability requirements.
  • CFR Part 23.206 provides an alternative compliance schedule for requirements in 23.202, when these requirements “are found to be technologically or economically impracticable”.
  • CFR 23.606 provides information on disclosure and record inspection.
  • CFR 45.2 provides additional recordkeeping requirements for record retention, retention form, record retrieval, including introduction of WORM storage medium.
  • CFR 45.5 introduces Unique Swap Identifier (USI), a primary swap identifier used for retention and retrieval.
  • CFR 45.6 introduces Legal Entity Identifier (LEI), a primary counterparty identifier used for retention and retrieval.
  • CFR 46.2 defines recordkeeping requirements for unexpired swaps on July 21st 2010 (Pre-enactment swaps) and swaps entered between July 21st 2010 and the compliance date (Transition swaps) 

What needs to be retained?

Transactional records – These records are associated with trades, or daily trading records. All of the records that make up a trade are included:

  • Pre trade execution – All oral (phone, voice mail) and written (email, chat, sms, fax) communication that led to trade execution. For example, Bloomberg chat identifying several potential trades followed up with a phone call confirming particular trade to be executed.
  • Trade execution – All information entered into a trade order system necessary for trade execution. Unlike some other Dodd Frank Title VII rules that explicitly identify the required data entities, like trade reporting, CFTC is expecting each SD/MSP to identify data entities they use in a trade. Each SD/MSP must include Primary Economic Term (PET) data entities, since they are reported to Swap Data Repository (SDR), thus requiring to be record kept.
  • Post trade execution – All post trade specific information, including Confirmation, Termination, Novation, Amendment, Assignment, Netting, Compression, Reconciliation, Valuation, Margining and Collateralization.
  • Related Cash and Forwards – In addition to record keeping of swap trades, each SD/MSP must keep records of every “purchase or sale for immediate or deferred physical shipment or delivery of an asset related to a swap where the swap and the related cash or forward transaction are used to hedge, mitigate the risk of, or offset one another.” Common industry approach is not to hedge at the individual position level, rather on aggregated portfolio level used for risk calculation and trading strategy. Recordkeeping requirements for related cash and forwards are the same as for swaps, they include pre trade execution, trade execution and post trade execution records.
  • New Dodd Frank required data entities – To standardize common swap trade information across the industry, CFTC has introduced the following data entities:
  • Unique Swap Identifier (USI) – Uniquely identifies swap transaction throughout the life of a swap. This data entity includes       unique code that identifies the registered entity creating the USI and transaction identifier. This approach prevents two different swaps from having the same USI.
  • Unique Product Identifier (UPI) – Uniquely identifies swap’s underlying product. This will be an industry standard for products, and every market participants will have to use it.
  • Legal Entity Identifier (LEI) – Uniquely identifies swap market participant. Creating and assigning this identifier will involve a number of organizations, including ISO, DTCC and ANNA.
  • Coordinated Universal Time (UTC) – International time standard based on International Atomic Time. This ensures all counterparties in a trade will have consistent time capture.

Non transactional records

These business and financial records demonstrate how each SD/MSP is running their SD/MSP business. They are closely related with SD/MSP registration documentation. Included are governance documents, organizational charts, biographies and resumes of executives, job descriptions, audit and compliance, financial records and complaints.

Retention

Dodd Frank recordkeeping retention varies depending on record types. Since transactional records provide trade related information, retention requirement is set to a life of a swap, plus five years. Exception to this is oral communication, where retention is one year. For non transactional records, retention is set to five years from the moment record was created. CFTC is very specific in the type of medium to be used for storing of the required records. They are leveraging CFTC rule 1.31, which is in existence well before Dodd Frank enactment. This rule mandates use of Write Once Read Many (WORM) compliant medium for storing. This type of storage includes devices where information, once written, cannot be modified. This, in view of the CFTC, ensures data used for trade reconstruction represents the original.

Retrieval

CFTC can request a trade reconstruction and every SD/MSP has obligation to provide the required data. While types of requests are not identified in any of the rules, what is known is that all records have to be searchable by transaction (USI, UPI), counterparty (LEI) within specified time (UTC).

  • Oral records must be readily accessible during the one year retention period (readily accessible is viewed as provided before the start of next business day).
  • Transactional records must be readily accessible during the life of a swap and during the first two years after swap termination.
  • Transactional records in the last three years of the retention period must be provided within three business days.
  • Non transactional records must be readily accessible during the first two years of retention period.
  • Non transactional records in the last three years of the retention period must be provided within three business days. 

What does this mean to you?

The single most important deliverable is trade reconstruction. By implementing comprehensive trade reconstruction all of the recordkeeping requirements will be met. Comprehensive trade reconstruction must include the following components:

Data

You have to understand what data is required to reconstruct a trade. While some of the required data is identified in the rules, a large number of data entities must be identified by SD/MSP. Combined this data must be sufficient to reconstruct a trade.

Location

Once the required data is identified it is necessary to catalog where data resides. Depending on the type of data the storage medium could be relational database, LAN and SharePoint servers, tapes and DVDs as well as paper. Dodd Frank recordkeeping is an ideal opportunity to consolidate storage mediums, especially ones that are difficult to maintain and search, like paper. Also, any non WORM storage medium needs to be migrated to WORM storage.

Retention

Any existing retention that does not comply with the recordkeeping retention requirements must be brought to the required level. For transactional records the retention will typically be achieved by combination of additional storage and change of purge processes. For non transactional records, this will typically be achieved by combination of additional storage and change of backup processes.

Process

The critical pieces of trade reconstruction are people and processes. While required data is retained in acceptable storage and within acceptable retention period, it is imperative to implement trade reconstruction process identifying required roles and responsibilities. Roles would include resources responsible for managing trade reconstruction and resources responsible for providing the required data.

What needs to be done?

Manual approach

This approach is based on minimal technology changes. The only technology changes that are likely required are the ones to extend record retention. To make this approach work it is critical to have central catalogue of data required for trade reconstruction. This central catalogue will identify data, location, established retrievability and resource responsible for retrieval. Next, this manual trade reconstruction process must be documented and included in the enterprise level documentation. To ensure this manual approach continues to function over time it is necessary to perform occasional reviews and “fire drills”. These activities would ensure that required data, process and roles and responsibilities are enabling continued SD/MSP registration.

Technology approach

While manual approach works, any trade reconstruction requests involving a large number of trades, with more than one counterparty across many days would require large team to support it.

Technology approach would provide a single portal for retrievability, with all disparate data being linked using rule based approach. Conceptual technology solution would include storage and linking of disparate data, and search.

Storage

Starting point for technology solution is identifying common storage to store data required for trade reconstruction. This could be brand new storage, or combination of new and existing storage. Main requirement for this storage is WORM compliance. Considering potentially large quantities of data, one of the evaluation criteria must be storage characteristics, including massively parallel processing (MPP) and direct attached storage device (DASD). It is common practice for a large number of firms to store some of the paper documents offsite using external document storage providers. These documents need to be included into overall the storage solution, likely requiring SLA update to provide the required data electronically within set period of time.

Linking

The storage must be accessible by the solution’s central piece, which is linking of disparate data. Linking is the brain of trade reconstruction technology solution. There are many different algorithms that can be used for linking, pattern recognition and predictive modeling being commonly used. One of the differentiating features of linking is ability to learn. This means that, out of the box typical linking module would already have a number of linking rules. These rules need to be updated as per each SD/MSP specific circumstances, and linking module does this via learning.

The learning process would typically involve the following scenario:

  • Setup initial rules using strict rule setup. This type of setup would include linking rules that are correct nearly 100% of time. Example would include linking a trader Bloomberg ID with trader email address.
  • To increase the linking success that would improve trade reconstruction it is necessary to setup and ultimately implement additional rules. Implementing these rules would start with reports that would provide loosely matched data. At this point human intervention is required to validate success, or lack of it for these rules. If a rule satisfies linking criteria rule would be reapplied to previously matched data as well as added to the linking module to be used for subsequent linking requests. If rule does not satisfy linking criteria, it needs to be updated and again verified by a human. In this instance already liked data is not updated.
  • Linking of disparate sources can be done at the point of data being loaded into storage as well as during trade reconstruction request. The first approach will be based on the linking rules available at the point data was loaded. The latter approach will leverage additional rules linking module has learner over time. This could be many weeks, months and even years after the initial data load. Also some additional data could potentially be available at the later stage that would improve linking success.

Search

Search is what is used when responding to a trade reconstruction request. Portal used for search must have access to all the required data. It must provide search capabilities by USI, UPI, LEI and UTC date range. The result of each search must be in the format that can be provided and easily consumed by the CFTC.

Some of the records required for search are non structured.  Examples include oral communication and paper documents. It is almost impossible to search these records in an automated fashion. However it is quite possible to convert oral communication into text, using voice to text transcription software. Paper document can be scanned prior to storing.

Considering potential cost of this type of technology solution it is always beneficial to leverage this solution for other, non Dodd Frank recordkeeping needs. Typical example of this use is trade data warehouse, which can enable firms with ability to slice and dice their swap trade related data. This would include trade-through analysis, best executions analysis, business metrics aggregated by desk, trader, asset class, product, account and customer. In addition, this type of technology solution can be a building block for all solution that will address other regulatory requirements, like Foreign Account Tax Compliance Act (FATCA) and Consolidated Audit Trail (CAT).

Operationalize trade reconstruction

To ensure this process is working it is necessary to update it when any major activity takes place. These major activities would include:

-       Introduction of a new trading system requiring trade data identification.

-       System migration requiring catalogue update to reflect new system.

-       Introduction of additional financial instruments requiring trade data identification.

 

Click here to download the complete whitepaper.