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
- Knowledge — the hub of all knowledge notes, with the alphabetical product run.
- Wikipedia: Credit default swap. This note follows its general definition.
- ORE User Guide, Product catalogue: products.tex, which inputs creditdefaultswap.tex. The upstream project is OpenSourceRisk/Engine.