The previous articles traced InterestRatePayout through all four F-PAL stages — from economic intent to settled cashflow. At its core, InterestRatePayout represents a scheduled obligation: someone pays interest to someone else, on known dates, according to an agreed rate logic. It is used for the fixed and floating legs of a swap, the coupon stream of a bond, the premium leg of a CDS — anywhere an interest-based payment follows a predictable schedule.

This article looks at the other leg of the CDS: CreditDefaultPayout. At its core, it represents a contingent obligation. Someone agrees to compensate someone else if a credit event occurs. There is no schedule, because the obligation itself is conditional.

One builds a time structure. The other builds a trigger structure.

In this article, I will walk through the CreditDefaultPayout type using the same F-PAL framework. The four stages still apply — but they map to different concepts than they did for InterestRatePayout. Where InterestRatePayout fills Stage 2 with schedules and Stage 3 with a formulaic calculation chain, CreditDefaultPayout fills them with trigger definitions and recovery mechanics. A single-name CDS on Finsight Tech Corp will serve as the running example.

The Shape of the Product

A credit default swap is not a monolithic product. It is two payouts with fundamentally different economic logics, sharing the same parent type and the same settlement infrastructure.

The premium leg is an InterestRatePayout — exactly the structure analysed across the previous four articles. The protection buyer pays 100bp quarterly on USD 10M. Same PayerReceiver, same priceQuantity, same PaymentDates, same dayCountFraction. Nothing about the premium leg is new.

The protection leg is a CreditDefaultPayout. Where InterestRatePayout builds a time structure, CreditDefaultPayout builds a different structure: generalTerms defines whose credit risk is referenced, protectionTerms defines what events trigger a payout, and transactedPrice captures the market context at execution. The two legs share PayerReceiver, priceQuantity, and settlementTerms from PayoutBase. Above that, they diverge completely.

CreditDefaultPayout — The Type Structure

Like InterestRatePayout, CreditDefaultPayout extends PayoutBase and inherits payerReceiver, priceQuantity, settlementTerms, and principalPayment. Above that, it adds three attributes of its own. None of them are schedules. None are calculation formulas. Each answers a different question about the credit contingency.

Three attributes. Each answers a different question.

generalTerms is mandatory (1..1). Without it, there is no CDS — you don’t know whose credit risk is being traded. It carries the reference entity, the reference obligation, and the pricing baseline. It enforces a required choice: single-name, index, or basket. You must pick one.

protectionTerms is repeatable (0..*). It defines what triggers a payout and which obligations qualify for delivery. It is optional because the protection terms may not be fully specified at the earliest stages of the trade lifecycle — a broker confirmation may reference standard terms without enumerating every deliverable obligation characteristic. When present, it can appear multiple times, for example when different sets of credit events apply to different obligation categories.

transactedPrice is optional (0..1). It captures the market context at execution — the spread, the upfront points, the quotation style. It is separate from the contractual premium rate on the InterestRatePayout leg because the market price and the contractual coupon are different things. The difference between them becomes the upfront payment.

Economic Agreement — On Whom, and at What Price?

The economic core of a CDS is simpler to state than an IRS but carries different complexity. An IRS exchanges one rate exposure for another. A CDS transfers credit risk. The protection buyer pays a periodic premium. The protection seller agrees to compensate the buyer if a credit event occurs on the reference entity.

The key question is: on whom?

GeneralTerms (1..1) answers this. It is mandatory — without a reference entity, there is no CDS. The reference can be one of three things, enforced as a required choice:

For our Finsight Tech Corp example, it’s the single-name path. ReferenceInformation carries:

ReferenceInformation {
    referenceEntity: LegalEntity { entityName: "Finsight Tech Corp" }
    referenceObligation: ReferenceObligation {
        security: Security {
            identifier: "US345370CZ42"
            debtType: SeniorUnsecured
        }
    }
    referencePrice: Price { value: 1.00 }        // 100% of par
    allGuarantees: false
    referencePolicy: false
}

TransactedPrice

The premium leg uses the 1% standard CDS coupon (one of two standard coupons since the 2009 market reform, alongside 5% for high yield). But the market spread for Finsight Tech Corp at execution is 175bp. The difference is settled upfront.

TransactedPrice captures the pricing context:

TransactedPrice {
    marketFixedRate: 0.0175       // market spread was 175bp at execution
    initialPoints: 0.02           // upfront payment of 2% = USD 200,000
    quotationStyle: Spread        // the trade was quoted as a spread
}

marketFixedRate is what the market quoted (175bp). The contractual fixedRate on the premium leg is the standard coupon (100bp). The 75bp difference, present-valued over the ~3.25-year trade life using a risky discount curve, produces the upfront — initialPoints: 2% of notional. Conceptually:

Upfront ≈ (Market Spread − Standard Coupon) × Risky Duration = (1.75% − 1.00%) × ~2.7 years ≈ 2.0%

One point equals 1% of notional. If the market spread is wider than the standard coupon, the protection buyer pays upfront (positive points). If it is tighter, the seller pays upfront (negative points). The model stores the result in initialPoints — a single number that captures the present value of the spread difference over the trade life, rather than expecting downstream systems to compute it from the credit curve themselves.

Contractual Definition — What Triggers, and What Qualifies?

ProtectionTerms defines the contingent obligation. It has no schedule — no CalculationPeriodDates, no PaymentDates, no ResetDates. Instead it has triggers:

ProtectionTerms {
    creditEvents: CreditEvents {
        bankruptcy: true
        failureToPay: true
        restructuring: true           // included for North American corporate
        obligationAcceleration: false
        obligationDefault: false
        repudiationMoratorium: false
    }
    obligations: Obligations {
        notSubordinated: true
        specifiedCurrency: "USD"
        notContingent: true
        transferable: true
        maximumMaturity: 30Y
        notBearer: true
    }
}

The creditEvents list defines what counts as a default. The obligations list defines which bonds or loans of Finsight Tech Corp qualify for delivery if physical settlement is triggered. These are populated because the trade uses physical settlement — the protection buyer needs to know which bonds they can deliver.

Value Determination & Settlement — Two Paths from Trigger to Transfer

Value determination for a CDS does not follow a formulaic chain — there is no dayCountFraction, no compoundingMethod, no forecastAmount. Instead, when a credit event occurs, the payout amount is determined by market observation or by delivery. The CDM models both through the same SettlementTerms type inherited from PayoutBase.

Cash settlement means the protection seller pays the loss amount without the buyer delivering anything. The loss is measured by polling dealers for the market price of the defaulted reference obligation after the credit event. The ValuationDate structure — single or multiple dates — defines when the price is observed. The valuationMethod defines whether bid, mid, or offer quotes are used. The payout is (ReferencePrice − FinalPrice) × Notional. If the reference obligation is quoted at 40% of par after default, and the reference price is 100%, the seller pays 60% — USD 6,000,000 on a USD 10M notional.

Physical settlement means the protection buyer delivers a defaulted bond or loan to the seller, and the seller pays the reference price in return. The buyer can choose which eligible obligation to deliver, within the constraints defined by ProtectionTerms.obligations — not subordinated, USD-denominated, transferable, not bearer, and so on. The settlement must occur within the physicalSettlementPeriod, typically 30 business days. An escrow agent may hold the cash and securities during the exchange.

In both cases, the same SettlementTerms type handles the detail. For our Finsight Tech Corp example, the instance populates the physical path and leaves the cash path empty. The type does not change; the values do.

When a credit event occurs, settlement follows one of two paths:

The same SettlementTerms type that handled cash settlement for a vanilla IRS coupon now handles physical settlement for a CDS. The type is broad; the instance is narrow. For our Finsight Tech Corp example, the instance populates the physical path and leaves the cash path empty.

This completes the four-stage F-PAL path for CreditDefaultPayout: the reference entity and pricing context define the economic agreement; the credit events and deliverable obligations define the contractual terms; the recovery rate and reference price determine the value; the physical or cash settlement mechanism discharges it.

Conclusion

The difference between the two payouts in a CDS comes down to one word: scheduled versus contingent.

InterestRatePayout is scheduled. You know when payments will happen. The model builds a time structure — CalculationPeriodDates, PaymentDates, ResetDates — and a calculation chain that turns notional, rate, and day count into an amount.

CreditDefaultPayout is contingent. You don’t know if a payment will happen at all. The model builds a trigger structure — GeneralTerms for whose credit risk, ProtectionTerms for what events, TransactedPrice for at what market level — and a settlement mechanism that handles the recovery.

Both extend PayoutBase. Both inherit PayerReceiver, priceQuantity, and settlementTerms. Above that, they diverge completely. That is composition: one product, two payouts, different economic logics, same parent infrastructure.

In the next article, I will look at a third extension of PayoutBase: OptionPayout.

• *AI-Native Financial Data Foundation
• Uncategorized