A BRIEF INTRODUCTION TO

CREDIT DEFAULT SWAP

BENJAMIN HUSTON

THE AGENDA• Describe the mechanics of a CDS contract• Briefly explore CDS• Discuss DTCC’s Trade Information Warehouse (TIW)• Discuss the most important CDS data variables• Identify issues that you must be aware of when you work

with the CDS• Describe DERA’s CDS data filtering process

2

HOW A CDS CONTRACT WORKS

Protection Buyer

Protection Buyer

Protection Buyer

Protection Seller

Protection Seller

Protection Seller

Periodic Fixed Payments

Contract’s Notional Amount – Auction Price

Deliverable Obligation

Contract’s Notional Amount

If a credit event* occurs, the CDS contract is settled using one of the following methods

Cash Settlement

Physical Settlement

*Standard ISDA credit events include a reference entity’s bankruptcy, a failure to pay its reference obligations , or a restructuring of the terms of itsreference obligations. (Restructuring is often not considered a credit event in the US; however, in Europe, it typically is.)3

REASONS TO USE A CDS CONTRACTTo hedge your portfolio

• purchasing a CDS on a reference obligation that iscomparable to a credit asset that you currently own

To gain credit “exposure” • taking credit risk• speculating on default rates

To earn a spread• market-making• arbitrage

4

HOW A CDS CONTRACT CAN ENDEarly Termination

• Occurs when both counterparties agree to cash settle an outstanding CDS prior to its scheduled termination dateExpiration

• Occurs when an outstanding CDS reaches its scheduled termination date without a credit event taking placeReference Entity Default

• Occurs when a reference entity experiences a “credit event”Counter-Party Default

• Counterparties to a CDS can also trigger a default by 1) failing to pay a premium or deliver a reference obligation (theprotection buyer) or 2) failing to pay a protection payment once a credit event has occurred (the protection seller)

Assignment (“Novation”)

• Occurs when the rights and obligations of an outstanding CDS are transferred from one counterparty to another. Theparty that assigns its position is referred to as the “assignor.” The party that assumes this position is referred to the“assignee.” Both protection buyers and sellers can assign their positions. Assignment typically requires the consentof the remaining counterparty and involves a one-time cash payment between the assigning parties.

Multi-lateral Portfolio Compression (“Tear up”)

• Occurs when a trade compression service, such as Markit, is used to cancel (“compress”) multiple counterparties’offsetting CDS contracts. Compression preserves credit exposures while reducing counterparty risk.5

THE LIFE OF A CDS CONTRACT

CPs

TERMS

OTHER

*In this example, the buyer is the “party” and the seller is the “cparty” (counterparty). The CDS data show these as separate variables, but to help simplify this example these have been omitted.

THE LIFE OF A CDS CONTRACT

**Indicates that a simplifying assumption is being made.*This information was obtained from ISDA’s official credit event documents.7

EXAMINING THE CDS TRANSACTION DATA

Sample March 2012 Greek single-name sovereign CDS transactions8

March 2012 Greek single-name sovereign CDS transaction network9

March 2012 Greek single-name sovereign CDS transaction network10

EXAMINING THE CDS POSITION DATA

Sample Greek single-name sovereign CDS open positions, 3/2/201211

Greek single-name sovereign CDS open position network, 3/2/201212

Greek single-name sovereign CDS open position network, 3/2/201213

Greek single-name sovereign CDS open position network, 3/23/201214

Greek single-name sovereign CDS open position network, 3/23/201215

Greek single-name sovereign CDS open position network, 3/30/201216

EXAMINING THE CDS DATALinks to interactive weekly CDS stock and volume reports*

• January 2013, weekly open CDS single-name positions• January 2013, weekly change in open CDS single-name positions• January 2013, weekly CDS single-name transactions• January 2013, weekly CDS index transactions

*If you are viewing this slide in Powerpoint and the hyperlinks are not opening correctly, perform the following steps to circumvent the issue:1. Right click on a link that you would like to open and select the “Edit Hyperlink” option2. Highlight the website URL that appears and then press CRTL+C to copy it3. Press CTRL+V to paste the URL that you copied into the website address bar of your internet browser and then press ENTER

17

THE CURRENT SOURCE OF THE CDS DATADTCC

DTC NSCC FICC

DTCC/Deriv

Warehouse Trust Company, LLC

DTCC Derivatives Repository

Others...

Trade Information

Warehouse (TIW)

18

THE TRADE INFORMATION WAREHOUSE (TIW)• Operated by DTCC’s Warehouse Trust Company LLC• The “first and only centralized global repository for trade reporting and post-trade processing of OTC credit derivatives contracts”

• Opened in 2006; back-loaded a significant number of historical trades in 2008

• Contains approximately 98% of all OTC CDS trade records• Going forward, there will likely be competing repositories thanks to new CFTC swap data repository (SDR) rules

19

HOW THE WAREHOUSE COLLECTS ITS DATA

Gold Records• Records that have been confirmed by

both trade counterparties

Copper Records• Records that have been confirmed by

only one counterparty to a trade

20

THE MOST IMPORTANT CDS DATA VARIABLESThree categories of variables

• Those that relate to counterparties• Those that relate to reference entities• Those that relate to CDS contracts

21

CDS DATA IDENTIFIERSPrimary counterparty identifiers

• BUYER_ID: used to identify the purchaser (protection buyer) of a CDS contract• SELLER_ID: used to identify the writer (protection seller) of a CDS contract• SUBMITTING_PARTY: used to identify the party that submitted the CDS contract to DTCC• COUNTERPARTY1: used to identify the counterparty of the party that submitted the CDS contract to DTCC

• When the submitting party is the protection buyer, then BUYER_ID and SUBMITTING_PARTY will have the same value. Otherwise, BUYER_ID and COUNTERPARTY1 will be the same.

• When the submitting party is the protection seller, then SELLER_ID and SUBMITTING_PARTY will have the same value. Otherwise, SELLER_ID and COUNTERPARTY1 will be the same.

Primary reference entity identifiers

• RED_NAME: the best available option for identifying reference entities; BEWARE, it is riddled with typos• RED_CLIP_CODE: also be used to locate reference entities, but codes do not exist for older contracts

Primary CDS contract-related identifiers

• DTCC_REFERENCE_ID: used to identify individual CDS contracts• ISIN: used to identify a CDS contract’s underlying reference obligation

22

COUNTERPARTY AND REFERENCE ENTITY VARIABLES

Reference Entity Variable Name DescriptionJurisdiction the location of the reference entityMarket_Sector the market sector of the reference entityType the reference entity's institutional type (e.g., financial, sovereign)

Counterparty Variable Name DescriptionBUYER_NAME the account name of the protection buyerSELLER_NAME the account name of the protection sellerPARTY_TYPE_CD the party type of the contract record submitter ("buyside" or "dealer")CPARTY_TYPE_CD the party type of the contract submitter's counterparty ("buyside" or "dealer")

RGSRD_OFFC_LOC_CD the registered office location (country code) of the record submitterCNTRA_RGSRD_OFFC_LOC_CD the registered office location (country code) of the submitter's counterparty

23

CONTRACT VARIABLESContract Variable Name DescriptionTRANSACTION_TYPE identifies whether the transaction is a trade, termination, assignment, et ceteraactual_date the date that credit protection begins; used as a proxy for the date a trade occurred as wellSCHEDULED_TERMINATION_DATE the maturity date of the contractnotional_now the outstanding notional of a contract after taking into account partial terminations, et ceteraOUSTANDING_CURRENCY the currency that premium and protection payments are denominated inPRODUCT_TYPE identifies whether the contract is on a single name (CDS), index (CDX), or tranch (CDT) FIXED_RATE identifies the rate, in percentage points, that is used to determine premium paymentsPERIOD_MULTIPLIER takes numeric values, such as 3, that are used to determine premium payment schedulesPAYMENT_FREQUENCY used in conjunction with PERIOD_MULTIPLIER to determine how often premiums are paid

(e.g., "M", for monthly, and 3 indicate quarterly premiums) SINGLE_PAYMENT the amount of up-front payment that a CDS buyer is often required to pay a CDS seller at the initiation of a

contractPOST_TRADE_PAYMENT_AMOUNT the amount paid by the post-trade payer if a post-trade event occursMASTER_CONFIRM_TYPE identifies which standardized form, if any, is used to confirm the contractMATRIX_TYPE identifies whether the contract will use cash or physical settlementMATRIX_TERMS identifies which regional convention will be used for settlementTRANSACTION_STATUS identifies whether the contract has been "confirmed" by both counterparties or not24

HOW TRANSACTION DATA DIFFERS FROM POSITION DATA

Transaction datasets:• have been created each month since November 2011• are compilations of all transaction records that exist as of the date that a given transaction dataset was

created• contain between three and ten times as many records as positions datasets• contain approximately 100 different variables, twice as many as positions datasets• show each CDS contract related action (e.g., trades, terminations, assignments) as a separate observation

Position datasets:• are available in weekly increments for almost every week dating back to January 2010• are weekly “snapshots” of all the CDS transactions that are open as of the day that positions data is

collected• show nearly-identical, abbreviated versions of open transaction records twice – once from the protection

buyer’s perspective and once from the protection seller’s perspective• typically have variable names that differ from transaction dataset variable names• generally contain much less transaction-level information than is available in transaction datasets, except

when it comes to reference entity-related data; in this case, they contain unique information not available elsewhere (e.g., position buyer/seller names refer to firm names rather than account names, whereas transaction data uses account-level names)

25

UNRESOLVED DATA INTEGRITY ISSUES THAT YOU MUST BE AWARE OFLife-Cycle Processing

• RED_NAME, BUYER_NAME, and SELLER_NAME changes are sometimes incorrect after a reference entity or counterparty has undergone some sort of corporate restructuring event (e.g., a merger, an acquisition, or a bankruptcy)

• These changes can make it impossible to correctly attribute an outstanding CDS contract’s terms/rights/obligations to the actual entities' that are legally bound by these conditions

Central Clearing

• Records related to CDS contracts that have been cleared by a central counter-party (CCP), such as ICE, on the same-day that they are entered into only show that each of the counter-parties have traded with ICE. These records do not show that the two original counter-parties ever traded with each other. Moreover, it is impossible to recover this information from the data.

• Records related to CDS contracts that have been cleared by a CCP at any point after the trade has been entered into (“back-loaded clearing”) only show that the two counter-parties have traded. Back-loaded clearing does not involve a cash flow, so the original assignment records are considered “non-pricing forming” and are not retained in DERA’s filtered transaction datasets. These records are found only in unfiltered transaction datasets.

Assignments

• DTCC_REFERENCE_ID values sometimes change, making it impossible to trace an assigned contract back to its pre-assignment transactions unless the original DTCC reference ID (ORGNL_DTCC_REF_ID) is also provided.

26

LIFE-CYCLE PROCESSING EXAMPLEWikipedia excerpts describing a famous acquisition:

• In October 2007, a consortium consisting of the Royal Bank of Scotland Group, Fortis and Banco Santanderacquired ABN AMRO.

• ABN AMRO was divided into three parts, each owned by one of the members of the consortium.

• RBS and Fortis soon ran into serious trouble: the large debt created to fund the takeover had depleted thebanks' reserves just as the financial crisis of 2007–2010 started.

• The Dutch government stepped-in and bailed out Fortis in October 2008, then split ABN AMRO's Dutchassets (which had primarily been allocated to Fortis), forming a new ABN AMRO.

27

CENTRAL CLEARING EXAMPLESame-Day Clearing

Clearing of a “Back-loaded” Trade

• Notice that same-day clearing involves no cash flows

• The only way to figure out whether a back-loaded trade has been cleared is to check whether the word‘ICE’ appears in the REFERENCE_SUPPLEMENT column28

ASSIGNMENT EXAMPLE

• This example shows a case where the original transaction record, the one that corresponds with a“Trade” transaction type, cannot be located.

• The earliest record, the “Assign Entry,” shows an old DTCC reference ID that is all zeros, so thetrail ends here.

29

HOW DERA PROCESSES ITS DATAFrom DTCC to DERA

• DTCC regularly sends DERA gigantic text files that contain all of its transaction and position related data

From DERA to YOU• DERA runs several programs that convert these text files into distinct transaction and

position SAS datasets• Weekly position datasets are stored in the D1-SAS2 server’s Pos2* library without

undergoing any further processing• Monthly transaction datasets are cleaned/compressed using an internally created

SAS program (“filter”) that was designed to remove non “price-forming” (i.e., non cash flow related) observations

• Once the filter finishes its processing, two types of transaction datasets, one that has not been compressed and one that has been, are stored in the Shared* library

*located in /data1/CDS/POSITIONS2/** located in /data1/CDS/SHARED/30

A CLEANED AND COMPRESSED EXAMPLEPRE-FILTER

POST-FILTER• the blue row was deleted because it was a duplicate submission• the red rows were deleted because they were “exit” records

RECOMMENDATIONS FOR AUGMENTING YOUR CDS DATASETS

• Roll-up counter-parties into “counter-party families”• Convert all outstanding notional amounts into USD equivalents• Compute CDS maturities (“tenors”)• Compute net notional amounts for each counterparty and each

reference entity• Use ISINs to pull additional reference obligation data from

CompuSTAT• Take Jurisdiction, Market_Sector, and (Institutional) Type tags from

position datasets sets and add these to transaction datasets

32

FURTHER READINGReadings that discuss general credit default swap mechanics

• Introduction to Credit Derivatives, Vinod Kothari• Credit Derivatives: An Overview, David Mengle• Credit Default Swap Primer, Bank of America• The JP Morgan Guide to Credit Derivatives, JP Morgan• Innovations in Credit Risk Transfer, Darrell Duffie

DERA documents that make use of DTCC’s CDS data

33

APPENDIX

DESCRIPTION OF DATA CLEANSING STEPSData Cleansing Step Description

Delete bogus confirmations This step deletes transactions that have either an invalid confirmation status or non- sense DTCC reference numbers.Delete old leg trades This step deletes records that relate to the counter-party which is assigning its role in a CDS contract to a third party.Delete double submissions This step identifies records submitted by both counterparties to a transaction and counts them only once to prevent over-counting.Delete "DTCC mistakes" This step is an ongoing mystery. No one who presently works at DERA knows what DTCC's mistakes areDelete participant errors This step deletes more counterparty over-submissions and other miscellaneous submission errors (e.g., a contract that claims to be standard but does

not follow standard terms).Delete negative notionals This step deletes records that have negative outstanding notional amounts.Delete exits and assigned exits This step deletes records that relate to credit events ("exits") or to a counter-party that has assigned his position in a contract ("assigned exit").Delete inside-out trades This step eliminates “inside-out trades.” Inside-out trades are transactions that occur from “bulk novations” (i.e., the simultaneous novation of a

large number of one entity’s CDS obligations to that of another entity ), “re-names” (i.e., the legal name change of an entity that is a party to a CDS obligation) , “account swings” (i.e., the adjustment of outstanding CDS obligations in response to account consolidations occurring within a firm); and reorganizations (i.e., the adjustment of CDS obligations in response to actions taken by an entity to legally restructure itself). The motivation for deleting inside-out transactions is simply to mitigate the double-counting of records.

Delete vender-initiated terminations This step eliminates “vendor initiated terminations” (VIT). Vendor initiated terminations are transaction terminations that occur as a result of a clearing house’s (vendor’s) use of same-day clearing procedures. The VITs records contained in DTCC’s transactions data are almost exclusively transactions that were cleared using ICE same-day clearing prior to 2011.

Delete intra-family trades This step deletes trades between counterparties that ultimately belong to the same legal entity.Delete prime-broker trades This step eliminates “prime broker trades.” Prime broker trades occur when a broker executes trades on a buyside client’s behalf. In such an event,

the same transaction information will submitted to DTCC by both the broker and the client, thus creating duplicate records.Delete replacement trades This step eliminates "replacement trades." Replacement trades are book-keeping trade records that have been generated by the trade compression

process.Delete cleared trades This step eliminates “cleared trades.” Cleared trades are simply transactions which have been processed by a central counter-party (clearinghouse).

Both the original parties to a trade and the clearinghouse(s) that clear this trade submit transaction information to DTCC, thus creating duplicate records.

Delete non-price forming amendments This step eliminates “non-price forming amendments.” Non-price forming amendments are any alternations to the contract underlying a CDS transaction that are not significant enough to cause the parties to also alter the transaction’s previously agreed upon payment terms.

35

CLEANING AND COMPRESSION RESULTS

36

CLEANING AND COMPRESSION RESULTS

37

CDS CONTRACT TIMELINE EXAMPLE:REFERENCE OBLIGATION INFORMATION

Name Hellenic Republic, 2002, 5.9%, 22/10/22, EarlyIssue Date 4/24/2002Maturity Date 10/22/2022Type of bonds Coupon bondsForm of issue Registered non-documentary bondsPlacement method Open subscriptionIssue status ExchangedNominal, minimum settlement amount EUR 1,000Amount 7,986,000,000 Initial issue amount 3,500,000,000 ISIN GR0133002155Day count fraction 30/360 (30/360 ISDA)Coupon 5.90%Coupon frequency 1 time per yearTrading floor Frankfurt S.E., Athens S.E., Berlin Exchange, EuroTLX

38