Most banks believe that because they can differentiate their risk at facility-level, there is not much point to develop more pooling criteria than what it is required in Basel. Therefore pooling tends to be fairly straight forward based on international best practice.
More over the page.
There are three main approaches,
1. Historical Observed PD pooling approach This key to this approach is to perform segmentation to the most granular(detail) level as possible. The selection of the risk drivers will have an direct impact to the final discrimination power of the pools, therefore choosing the pooling criteria is similar to the variables selection under a scoring approach (discrete vs continuos). Most people prefer to use their judgement in choosing the risk drivers such as account level score, customer level scoring, delinquency status, Time on book, products type, etc. The number of pools identified based on this approach is usually higher compare to the other two methods. This is because the more the risk drivers (up to a certain point) or the higher number of branches within each criteria, the better the separation powers between the pools.
2. PD model pooling approach Typically behaviour score or application score have been one of the major input of the PD model. Banks adopting this approach will build their pooling criteria for the purpose of the PD models, that is they will build different PD models based on the segment. For example, for time on book < 6mths, the bank will include application score into their PD models while for time on book >= 6 mths, they will use the behaviour score instead. Since model can be applied at account level, the objective of pooling criteria is to optimise the segment for model development instead of the discriminative of the pools.
3. Scorecard to PD pooling approach Banks can re-calibrate their scorecard model to estimate PD over the standard default definition (90dpd) and time horizon(1 year). Calibration can be done using observed default frequency over time, or by developing a single characteristic logistic regression model using the application score as the explanatory variable, and the Basel default state as the dependent variable.
This method, the score can be used as a pooling criteria such that different scorebands equate to different pools.
Will be great to hear what other are doing in the industry. Please post your comments in relation to your experiences in this area!
12 comments
20 December, 2006 at 18:39
J P
Hi! From a spanish bank.
We use the third method including before a segmentations by time on book of the facility. Our supervisor, in the IRB validation process, said to us that the result of the PD calibration has to be a final look up table by the different levels of segments or homogenous groups of risk (combination of time on book-interval of scores) Our problem is how to delimitate the intervals due that them would have to be stadisticaly diferent… Do you know some pubilshed referents or articles abou that?
21 December, 2006 at 00:31
bruce
The segmentation is to group facilities into groups where, within each group the risk is similar and between the groups the risk is measurably different. In principle, the factors that are used to select a segment must be able to rank risk. If you use ‘time on book’ have you proved that this ranks risk?
In the end the number of risk segments is based on the diversity of risk within a portfolio. The key object is to not have too large a proportion within one segment and a measurable difference in risk between segments. The limit is when a further split creates two groups that are not measurably different. Depending on the portfolio, this could be five, twenty or more. As long as you can justify it with statistical evidence there is no set rule but too few indicates a lack of ability to rank risk.
10 February, 2007 at 18:00
Shyamsundar Baliga
I believe pooling should be based on the risk drivers rather than historical PD or application credit score.
The objective of retail pooling is to classify the population into homogeneous pools, meaning that accounts within a given pool should all have similar borrower and transaction risk characteristics and hence default probability, and the pools should be heterogeneous in comparison.
Credit score (application scoring) is a composite number derived from weights assigned to various risk drivers, and these weights are usually attached based on past experience. Hence it can be argued that credit score is essentially a method of estimating default probability of the account being scored, by reflecting on the performance of past accounts having similar risk characteristics.
A fundamentally different approach is to pool past accounts purely on the basis of similarity of risk characteristics or risk drivers, without using default information or information about the performance of these accounts. Having thus pooled the accounts, default information can be used to back test the pooling method.
With a bank’s retail data that I am working on, we have used a few statistical techniques like classification tree analysis (using CART), discriminant analysis etc. However in contrast to my discussion above, we used default information to arrive at pooling methods. We typically short list about 12 to 15 risk drivers and then use these methods to identify the most significant risk driver or the few most significant risk drivers. For example in a car finance portfolio the key risk drivers would be the geographical location, vehicle segment, product (new car or pre-owned car), customer profile, etc. Problems surfaced when classification tree analysis gave inconsistent results, for example for a group of accounts sourced in a particular year, geography seemed to be the most significant, whereas for accounts sourced in another year the product seemed to be the most significant.
We are now trying factor analysis and cluster analysis without using default information.
Your views?
10 February, 2007 at 18:07
ozrisk
Shyamsundar,
I will have to get “coldies” (one of the other contibutors) in on this one. I would tend to agree with you, although I think the results would be similar either way (you would hope so if you have a robust pooling method, but coldies is more experienced in this area.
I will make sure he sees your question.
12 February, 2007 at 09:34
coldies
I support your views that pooling should be based on risk drivers than just PD. Afterall, that is consistent with the requirements of Basel. However, as you mentioned, scoring is a composite number derived from various risk drivers, it is most likely to be able to differentiate risk and most appropriate in classifying the population into homogeneous pools (based on risk).
What I do believe though is that although scoring will be a strong candidate to classify the retail populations into different pools, there maybe other necessary risk drivers such as “month on books” or “delinquency”. In fact if you drill down further, you may possibly come up with another 12-15 other risk drivers as you quoted. It is common for banks to employ statistical techniques such as cluster analysis, decision tree to come out with what so called the “homogeneous” segments. However as you experienced, these criteria are sensitive to the data and there are only limited human intervention in deciding the pools.
Therefore even though statistical analysis are useful. It may add little value from a business point of view. Particularly if you business are already managing the portfolio on an account level (i.e. scoring, etc.) I always have a hard time convincing my client the value of pooling if they are already managing their portfolio at the facility level. Another issue with statistical segmentation of pooling is that it will be extremely difficult to convince the business in interpreting these “statistical” pools. Therefore it make more sense to only have the least number of pooling criteria to comply with the Basel requirements.
While I agree with your approach, I question the extra value it would generate if you were to statistically “model” the pool. While I was in UK, I heard that FSA (UK Supervisor) is considering waiving the requirements for AIRB banks to have pools if they can demonstrate that they are already managing the facilities on the individual account level.
6 June, 2007 at 22:25
Shyamsundar Baliga
I agree with you that statistical pools would be difficult to interpret or use in business, and that application score based pools would be much easier to implement and convince. Hopefully they would effectively differentiate risk too, provided the rating system is effective. And indeed, taking a simple view of things — “internal rating” based approach of Basel II should recognise internal ratings.
That said, there are some drawbacks of score based pooling approach which I can see if I choose to play the devil’s advocate. (The multiplicity of approaches arises from these drawbacks and from the uncertainty over how the Supervisor might view this issue.)
(1) Going by the”requirement” of Basel II the pools have to be homogeneous in characteristics. Score based pooling is in effect PD based pooling. By this one would pool similar-PD accounts together, irrespective of their characteristics, and hence the pool would not be “homogeneous”. (For example, accounts with entirely different characteristics may coincidentally have similar PD, and hence may get pooled together.) Would this be in line with Basel II requirements or acceptable to the Supervisors ?
(2) Score/PD is essentially a risk parameter rather than a risk characteristic/driver, and hence it may not be correct to ignore other risk parameters (like LGD or Maturity) in this pooling approach. (Meaning shouldn’t one also consider LGD for example in pooling.)
(3) As you have already pointed out, scoring may not take into account some characteristics like seasoning or performance.
In some countries that are allowing advanced approaches for credit risk like UK or Australia, have the financial Supervisors expressed their views or preferences for/against any method of pooling ?
7 June, 2007 at 19:59
bruce
Good questions.
Your question, is it appropriate to create risk segments based on PD levels only, is valid. One thing to consider is the risk of a single exposure verses the risk of the pool. The pool is rated by a default weighted average but if you can assess risk at an exposure level how is it distributed within the pool verses this average. Since capital is based on the average, it should be a fair representative of each case. So the answer is to consider whether the result is appropriate to each exposure.
There is also a conflict between application scoring which often has a longer outcome period than the Basel one year window. Also, App scores are often not developed using the same default definition. This is why behavioural score as commonly used. They consider application data (static over the life of the exposure) and transactional or behavioural data which can change. This can be far more accurate (for Basel) but there are differences in the modelling approach.
A key leason is that decisions made at this point in the IRB journey have considerable impacts later on. For exampling in validation , stress testing and disclosure. However, it is often difficult to anticipate the issues, so you may be lucky or possibly not.
good luck.
4 August, 2007 at 14:58
Rakesh Kumar
Dear Shyam
Each product has different risk drivers and segmentation should be done accordingly. However the common thread across all products is the earning capacity of the borrower. If you pick up car pool, you will realise that D segment cars always show lower delinquency levels though resale value of the car is low. Same way entry level car segment will always show higher delinquency, though product may have a higher delinquency. Therefor All pools should be segmented on atleast three parameters.
Income wise, LTV wise (Low income person will default less if he has put in higher margin) and geography. Broadly these parameters will always be key differentiators across all poducts. The main question I want to ask is that on retail book, every month new contracts are added and historical defaults will be different for different pools (i.e contract sourced in different months). what should be our approach. should be track default (90+) based on static pool on a month on month basis. If yes, having done that if we have 12 observations every year and we have data for 5 years, what need to be done. should we take the mean or plot a trend and extrapolate it. These are the questions that needs to be clearly answered
3 April, 2008 at 13:29
Clive
Just noticed these interesting posts and some of the points will be picked up as they link with the current (April 2008) threads of discussion.
3 September, 2008 at 04:18
sumitsage
Can somebody explain what is meant by management of risk at Facility level? Banks ordinarily handle risk through scoring. If a customer has more than one account, would the bank have one facility level behavior score for it or multiple product level behavior scores?
I understand Basel II requires retail pools, that in turn are constituted at an account level aggregation of data. THis literally means, one customer can be a part of multiple pools if he/she has more than one retail credit product. How is Facility level risk to be understood in the content of retail pooling? Is Facility level only for the purpose of taging a LGD to a pool?
Grateful if anyone can explain with an example. Thanks!
7 September, 2009 at 17:11
Mriganka
Hi guys,
I am working as a consultant for one year and currently doing a search on this pooling topic. So far I have understood that the pooling or segmentation of customers should be done such that the risk characteristics are homogeneous in each pool.
Methods applicable:
k-means, classification trees.
Variables can be used to cluster:
Product type,borrower risk (age, score etc.), delinquency status, vintage etc.
Question1: If a factor (say,age) is already used in scoring then we should not use both that factor and score. That will be double counting. Isn’t it?
Qn2: Once we derive the clusters or segments, then how should we compute the pooled PD or LGD etc.? What should be done in case of a PD/LGD model exists and in case they do not exist?
Qn3: Can we use historical default rate of each pool as PD estimate and will that be Basel compliant?
Please clarify my queries if possible.
23 February, 2010 at 23:40
Sadi Farooqui
The advantages of PD pooling in terms of collecting the specific segments from the main source is effective but when it comes to testing the scorecards especially within the boundaries, the problem might be too material. In retrospect, banks in South Africa have done very well with the pooling method where they have collected the most accurate information at both behavioural level and application for retail scorecards thus mapping /calibrating the PDs against the scores. Having audited the stability of the scorecards for the big banks, our findings have shown that pooling method does pose significant challenges within boundaries and the proof is one extract where i can bravely pick out 1 account sitting in that pool when it is suppose to be in a different segment. So the next biggy for pooling is to prepare codes for system analysts that can seperate apples from the tomatoes. Afterall capital at regularity level is assumed to be originating from a granular portfolio with no cross overs.
Sadi Farooqui
Risk-Tech Consulting