Credit Default Swap

Table of Contents

A credit default swap trades the default risk of a reference entity. The buyer pays a premium and receives compensation if the entity defaults. ORE models it with the trade type CreditDefaultSwap, with single-name and quanto forms. This note records the domain grounding, as ORE documents it in its product catalogue.

1. Identifiers

What a trader books it as, and what to grep for. The codes are the trade type catalogue's, which is what the database enforces.

Field Value
Full name Credit Default Swap
Short name CDS
ORE Studio product code CreditDefaultSwap
Asset class credit
Family Swap
ORE trade data node CreditDefaultSwapData
ORE documentation creditdefaultswap.tex

2. Summary

A credit default swap (CDS) is a bilateral contract on the credit of a reference entity. The protection buyer pays a running premium. In return, the seller compensates the buyer if the entity defaults or experiences a credit event. The payment is tied to a financial instrument issued by the entity. The premium leg is a fixed leg; its direction marks the trade as bought or sold protection. A fixed recovery CDS sets the recovery rate in the contract. The product is the atomic building block of the credit family in this set.

3. Detail

3.1. What it is

ORE defines the product as follows:

A CDS is a credit derivative between two counterparties. The buyer of a CDS makes premium payments to the CDS seller. In return, the seller agrees that in the event that an underlying reference entity defaults or experiences a credit event, seller will compensate the buyer, in relation to a financial instrument issued by the reference entity.

Source: ORE User Guide, Products catalogue, creditdefaultswap.tex.

3.2. In plain terms

A CDS works like insurance on a loan or a bond. The buyer pays a regular premium, like an insurance policy. If the borrower defaults, the seller pays the loss. The buyer keeps credit protection without holding the underlying instrument.

3.3. How it works in ORE

The trade uses a CreditDefaultSwapData block. It must name the credit curve with a CreditCurveId, or carry a ReferenceInformation node instead. That node names the reference entity, the tier, the currency, and the documentation clause. The LegData sub-node is a fixed leg and holds the recurring premium. Payer true means the trade buys protection. Payer false means it sells protection.

The trade data also controls the default mechanics. ProtectionStart is the first date on which a credit event triggers the contract. For standard CDS it is the trade date. SettlesAccrual decides whether the accrued premium is due at default. ProtectionPaymentTime sets when protection and accrual pay, at default, at period end, or at maturity. An UpfrontFee and UpfrontDate express an off-par premium as a decimal share of the notional. A FixedRecoveryRate turns the trade into a fixed recovery CDS.

The quanto form is a CDS whose denomination and settlement currencies differ. The catalogue example has a notional of 50 million BRL and pays a 6 percent premium. The premium converts to USD with an FX fixing two days before settlement.

3.4. Mathematical notes

The premium leg is the present value of the running premium until maturity or default, the risky annuity. The protection leg is the present value of the loss on default, the notional minus recovery. The fair running premium makes the two legs equal. A fixed recovery CDS uses the contract's FixedRecoveryRate instead of the market recovery.

3.5. What moves its value (static sensitivities)

  • The credit curve of the reference entity. It is the dominant driver. A spread widening raises the value of bought protection.
  • The discount curve of the premium currency. It prices the risky annuity.
  • The recovery assumption. A lower recovery raises the protection payment and the value.
  • The quanto FX rate, when the currencies differ. It converts premium and protection flows.
  • The premium and the upfront fee. They fix the running cost.

A protection buyer gains when the credit worsens. A protection seller gains when the credit improves.

3.6. How the profile ages (dynamic sensitivities)

The trade pays premium on its schedule until maturity or a credit event. At default, the protection payment settles and the trade ends. The risky annuity shortens as time passes, so the running premium carries less and less value. Near maturity, only near-term default risk matters. After the protection start date, all credit events count.

3.7. Why a customer would want it

A lender or a bond holder buys CDS to hedge credit exposure. A bank sells protection to earn premium on names it likes. Dealers quote CDS to manage their credit books. In ORE Studio a customer books CDS to value them, run credit sensitivities, and feed XVA on the ORE engine.

3.8. Example

ORE's catalogue shows the single-name form with a credit curve:

<CreditDefaultSwapData>
  <IssuerId>CPTY_A</IssuerId>
  <CreditCurveId>RED:008CA0|SNRFOR|USD|MR14</CreditCurveId>
  <SettlesAccrual>Y</SettlesAccrual>
  <ProtectionPaymentTime>atDefault</ProtectionPaymentTime>
  <ProtectionStart>20160206</ProtectionStart>
  <UpfrontDate>20160208</UpfrontDate>
  <UpfrontFee>0.0</UpfrontFee>
  <LegData>
    <LegType>Fixed</LegType>
    <Payer>false</Payer>
    ...
  </LegData>
</CreditDefaultSwapData>

Source: ORE User Guide, Products catalogue, creditdefaultswap.tex, listing CreditDefaultSwap Data (leg detail abbreviated).

The family siblings are the Index Credit Default Swap and the Synthetic CDO.

4. See also

Emacs 29.3 (Org mode 9.6.15)