Redacted revision of a presentation on over-the-counter CDS networks which was delivered to the SEC's Division of Economic Research and Analysis

1. A BRIEF INTRODUCTION
TO
CREDIT DEFAULT SWAP
BENJAMIN HUSTON

2. 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

3. 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 its
reference obligations. (Restructuring is often not considered a credit event in the US; however, in Europe, it typically is.)3

4. REASONS TO USE A CDS CONTRACT
To hedge your portfolio
• purchasing a CDS on a reference obligation that is
comparable 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

5. HOW A CDS CONTRACT CAN END
Early Termination
• Occurs when both counterparties agree to cash settle an outstanding CDS prior to its scheduled termination date
Expiration
• Occurs when an outstanding CDS reaches its scheduled termination date without a credit event taking place
Reference 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 (the
protection 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. The
party 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 consent
of 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

6. THE LIFE OF A CDS CONTRACT
C
P
s
T
E
R
M
S
O
T
H
E
R
*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.

7. 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

8. EXAMINING THE CDS TRANSACTION DATA
Sample March 2012 Greek single-name sovereign CDS transactions8

9. March 2012 Greek single-name sovereign CDS transaction network9

10. March 2012 Greek single-name sovereign CDS transaction network10

11. EXAMINING THE CDS POSITION DATA
Sample Greek single-name sovereign CDS open positions, 3/2/201211

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

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

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

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

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

17. EXAMINING THE CDS DATA
Links 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” option
2. Highlight the website URL that appears and then press CRTL+C to copy it
3. Press CTRL+V to paste the URL that you copied into the website address bar of your internet browser and then press ENTER
17

18. THE CURRENT SOURCE OF THE CDS DATA
DTCC
DTC NSCC FICC
DTCC/Deriv
Warehouse Trust
Company, LLC
DTCC
Derivatives
Repository
Others...
Trade
Information
Warehouse (TIW)
18

19. 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

20. 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

21. THE MOST IMPORTANT CDS DATA VARIABLES
Three categories of variables
• Those that relate to counterparties
• Those that relate to reference entities
• Those that relate to CDS contracts
21

22. CDS DATA IDENTIFIERS
Primary 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

23. COUNTERPARTY AND REFERENCE ENTITY
VARIABLES
Reference Entity Variable Name Description
Jurisdiction the location of the reference entity
Market_Sector the market sector of the reference entity
Type the reference entity's institutional type (e.g., financial, sovereign)
Counterparty Variable Name Description
BUYER_NAME the account name of the protection buyer
SELLER_NAME the account name of the protection seller
PARTY_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 submitter
CNTRA_RGSRD_OFFC_LOC_CD the registered office location (country code) of the submitter's counterparty
23

24. CONTRACT VARIABLES
Contract Variable Name Description
TRANSACTION_TYPE identifies whether the transaction is a trade, termination, assignment, et cetera
actual_date the date that credit protection begins; used as a proxy for the date a trade occurred as well
SCHEDULED_TERMINATION_DATE the maturity date of the contract
notional_now the outstanding notional of a contract after taking into account partial terminations, et cetera
OUSTANDING_CURRENCY the currency that premium and protection payments are denominated in
PRODUCT_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 payments
PERIOD_MULTIPLIER takes numeric values, such as 3, that are used to determine premium payment schedules
PAYMENT_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
contract
POST_TRADE_PAYMENT_AMOUNT the amount paid by the post-trade payer if a post-trade event occurs
MASTER_CONFIRM_TYPE identifies which standardized form, if any, is used to confirm the contract
MATRIX_TYPE identifies whether the contract will use cash or physical settlement
MATRIX_TERMS identifies which regional convention will be used for settlement
TRANSACTION_STATUS identifies whether the contract has been "confirmed" by both counterparties or not
24

25. 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

26. UNRESOLVED DATA INTEGRITY ISSUES
THAT YOU MUST BE AWARE OF
Life-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

27. LIFE-CYCLE PROCESSING EXAMPLE
Wikipedia excerpts describing a famous acquisition:
• In October 2007, a consortium consisting of the Royal Bank of Scotland Group, Fortis and Banco Santander
acquired 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 the
banks' 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 Dutch
assets (which had primarily been allocated to Fortis), forming a new ABN AMRO.
27

28. CENTRAL CLEARING EXAMPLE
Same-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

29. 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 the
trail ends here.
29

30. HOW DERA PROCESSES ITS DATA
From 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

31. A CLEANED AND COMPRESSED EXAMPLE
PRE-FILTER
POST-FILTER
• the blue row was deleted because it was a duplicate submission
• the red rows were deleted because they were “exit” records

32. 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

33. FURTHER READING
Readings 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

34. APPENDIX

35. DESCRIPTION OF DATA CLEANSING STEPS
Data 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 are
Delete 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

36. CLEANING AND COMPRESSION RESULTS
36

37. CLEANING AND COMPRESSION RESULTS
37

38. CDS CONTRACT TIMELINE EXAMPLE:
REFERENCE OBLIGATION INFORMATION
Name Hellenic Republic, 2002, 5.9%, 22/10/22, Early
Issue Date 4/24/2002
Maturity Date 10/22/2022
Type of bonds Coupon bonds
Form of issue Registered non-documentary bonds
Placement method Open subscription
Issue status Exchanged
Nominal, minimum settlement amount EUR 1,000
Amount 7,986,000,000
Initial issue amount 3,500,000,000
ISIN GR0133002155
Day count fraction 30/360 (30/360 ISDA)
Coupon 5.90%
Coupon frequency 1 time per year
Trading floor Frankfurt S.E., Athens S.E., Berlin Exchange, EuroTLX
38