Default Risk, Explained to a Developer

In the article on counterparty risk, EAD, PFE and CVA answered a specific case: an exposure that varies over time, on a bilateral derivative contract. Default risk is the more general problem counterparty risk is just one application of: it comes up in exactly the same shape for a bank loan, a corporate bond, or a credit line, any time an amount is owed in the future by someone who might not be able to pay it back.

PD: estimating a probability of default#

PD (Probability of Default) answers a direct question: over a given horizon, usually a year, what's the probability this borrower defaults? It's the financial equivalent of a historical failure rate: the same way you'd estimate a cloud provider's reliability from its incident history, a bank estimates a borrower's PD from its payment history, its financial structure, and its industry.

Rating agencies translate that work into a readable scale. The figures below are illustrative, not reference numbers to quote as-is: the actual PD behind a given rating varies by agency, by economic cycle, and by sector.

LGD: what you actually lose if default happens#

A default doesn't mean a total loss. LGD (Loss Given Default) measures the share you actually lose, once recovery is accounted for: LGD = 1 - recovery rate. A loan secured by a liquid asset (real estate, pledged securities) has a low LGD, often 20 to 40%, because the collateral caps the real loss. An unsecured credit, last in line to be repaid in a bankruptcy, has a high LGD, sometimes above 60%, because there's nothing to seize first.

EAD, already covered, a quick reminder#

EAD (Exposure At Default) was detailed in the article on counterparty risk: it's the amount exposed at the moment default happens. On a plain fixed-amount loan, EAD is simple, it's the outstanding principal. On a revolving credit line, it's more uncertain, because a borrower in difficulty tends to draw further on their line right before defaulting, which pushes EAD above the balance observed today.

The formula that ties the three together: Expected Loss#

The three building blocks combine into a single metric, expected loss:

Expected Loss = PD × LGD × EAD

Example: a 5,000,000 EUR corporate loan, rated BB (PD = 1.2%),
unsecured (LGD = 55%)

EL = 0.012 × 0.55 × 5,000,000
   = 33,000 EUR

That 33,000 EUR isn't a prediction about this specific loan, whose outcome is binary (default or no default). It's a statistical average, valid across a large portfolio of comparable loans: across thousands of BB-rated, unsecured credits, the average observed loss trends toward this figure, even though each individual loan ends up either fully intact or fully in default. The diagram shows how the three building blocks combine, on this exact example:

Expected loss vs unexpected loss: two different treatments#

This is the most useful distinction in the topic, and the one that sets up the capital requirement question directly. Expected loss is treated as a normal cost of doing lending business: a bank provisions for it in advance, it's built into the price of the credit, exactly the way you'd build the expected cost of customer support into a subscription's price.

What the provision doesn't cover is the gap between that average and a scenario where several borrowers default at once, during a recession, for instance. That gap is called unexpected loss, and it isn't covered by a provision but by equity capital, set aside precisely to absorb the day the average stops holding. That's exactly what Basel III and Basel IV regulate: how much capital a bank has to hold so that this unexpected loss doesn't put the bank itself into default.

Why this is good territory for a curious developer#

What makes the calculation interesting technically isn't the formula itself, three multiplications don't justify an article on their own. It's the estimation of each of the three parameters, which rests on statistical models trained on default histories, recalibrated regularly, and validated independently before being used to compute regulatory capital. That's the ground kotlin-counterparty-risk and Finance for Engineers make approachable, TDD-driven, with no need for access to a real banking system to understand where PD, LGD and EAD actually come from.