Basel systems are likely to make use of the application PD of each account, but this is not a comfortable fit because the Basel requirements are cross sectional whereas the App PD is longitudinal and not generally related to the same outcome window (OW).

The App PD is primarily for the purpose of decisioning: does the bank want to accept the application (made by some individual for some retail credit product).

At the front end the PD is usually presented as a score – merely a mathematical transformation of PD that is easier for general staff to handle – PDs can be a bit painful to look at because of decimal points, counting the leading zeroes, their inherent skewness, and potential confusion between decimal and percentage formats. Scores, by contrast, are chosen to span comfortable three-digit ranges, and are arranged such that high score = good applicant ( = low PD). This is done by linear transformation of the log(odds) which, if you are interested in it, you probably know all about.

So, in its simplest form, the computer knows that the cut-off score is (say) 567 and the applicant is declined if their score works out to be below this. Otherwise, referral, accept, etc.

This decisioning purpose is different from the Basel purpose of PDs. Originally, there would have been a business case for this product, modelling profitability of this line of business based on revenues, costs, and credit losses. This profitability model would ideally analyse a full product life cycle, but depending on the product, life cycles can be variable due to early closure, early repayment, refinancing and the like, which I will call “churn” below (although suggestions for a better term are welcome). A key input would be the default profile to be expected – how many defaults and at what stage (longitudinal MOB) in the account’s life cycle. The estimation of default profiles and churn profiles is not difficult given sufficient amounts of relevant data and the assumption that the future will be like the past (!?).

A common simplistic approach for building an application model is to settle on some fixed OW – such as 24 months – and do the modelling on the basis of predicting this “bad rate @24 months”.

There is no reason for such an OW to equal the Basel OW of 12 months. Its purpose is to help the business make the best decisions on new applications. Presumably, for some products such as HLs, this would require a profitability model that looked well beyond the first 12 MOB of the account. In my experience, defaults on HLs arise more in later years. If this were a technical discussion, we would now pause to sketch hazard graphs AWML.

So, quite likely, a bank’s App PDs are built on a different OW than 12 months, and are therefore not immediately commensurate with Basel needs. Furthermore, App PDs are longitudinal not cross-sectional, so even if it were a 12-month OW, it would be referring to the first 12 MOB for that account, which wouldn’t be the coming 12 months unless that account opened this month. A typical account this month may be 29 MOB, so for Basel purposes one would want to know the conditional probability, given that the account is not in default at MOB=29, that it would go into default during MOB=30 through 41 inclusive. Whilst this calculation could be done using the hazard curve, I don’t think many analysts go to this level of detail.

Rather, there are several simpler potential ways that the App PD can be incorporated for Basel purposes. Follow-ups to come but see also an earlier ozrisk discu

ssion.