New definition of default: tips to simulate the future impact!

While carrying an action plan for implementing the new definition of default in the IT systems & processes, in its internal policies as well as in the internal models, every bank is highly interested in predicting the impact that the application of the new default definition would have on various aspects like:

• the variation of the non-performing portfolio in amount and in number of defaulted obligors & contracts;
• the variation of the stock of provisions resulting from new default entries/exits; 
• the effect on key risk parameters such as PD & LGD and therefore on internal models;
• and the variation of the RWA amount and the capital ratio of the institution.

That prediction can be achieved via a comprehensive simulation of the default under the new definition on the available historical data of the credit portfolio. Knowing the broad impact of the new definition on capital requirements, IFRS 9 models, precision is highly recommended for the sake of planning of own funds requirements.

To perform an accurate simulation on data of the new default definition few aspects must be considered, mainly:

• Preparation of the historical data set;
• Building the obligors base;
• Calculation of exposures & past due obligations and counting of days past due (DPD) on daily basis;
• Applying contagion rules;
• Re-initialization of default status at the initial snapshot date

We provide some practical tips regarding the above-mentioned aspects.

Simulating the new default definition on data at a time (t), will rely on a mix of two sources:

• Prior to time (t): adjusted historical data according to the new default rules especially materiality thresholds, contagion and exit from default status;
• Starting from the time (t): new data collected, i.e. future daily portfolio snapshots on which the new definition of default rules are run on daily basis in order to detect new entries in default or new exits to sound status.
   

Ideally, it is preferable that the impact analysis is built on newly collected data. Indeed, the new rules are easier to apply on the new flows. The default definition is applied homogeneously and less data availability issues are faced. However, the time to entry in application of the new default definition is short and therefore the new observations window is not large enough to allow a representative simulation as well as accurate estimates of risk components, like PD, LGD or Cure rates.

That’s the reason why it is also necessary to rely on readjusted historical data. The latter is readjusted with a sufficient margin of conservatism, in particular where specific workarounds/proxies are applied to manage data unavailability issues like for instance the use of historical monthly snapshots due to unavailable historical daily data.

This is a significant challenge. On the one hand, certain criteria of detection of default status, especially some of the indications of Unlikeliness To Pay (UTP), turn out not to be even used by the institution and therefore very complex to rebuild retroactively on historical data due to lack of attributes in the existing IT systems / and in database that allows identifying such triggers. 

For instance, the UTP indication “sale of credit obligation” due to the occasional character of such event it is possible that the institution doesn’t manage a sale of a portfolio of credit obligation in a specific IT system or store the information in a classical database. It may be a file / record prepared one time and stored somewhere. By consequence it will be challenging to identify those obligations flagged as sold. Even if we manage to do so, it is not guaranteed that all attributes necessary to calculate whether the economic loss is higher than 5% are available and/or reliable.

Another challenge is the identification of technical defaults that result from errors in IT systems or misunderstandings with clients rather than realization of credit risk. That generally comes from the fact that such events are partially/not covered by the institution operational policies and systems. The data at disposal could be not rich enough to allow retrace technical default situations on historical data.
 

So, what to do?

It is recommended to deal with such obstacles combining common sense and enough dose of conservatism with the support of experts.

1. whenever possible to rebuild missing historical information without significant time waste, do it in and document it. For instance, in the aforementioned example of missing data on sold credit obligations, retrieve the list of sold credit obligations, liaise with collection and accounting teams to retrieve essential attributes like outstanding amount of each loan at the moment of sale, the sale price of each loan and the date of sale. After rebuilding the list, it will be possible to import into your impact analysis database and use it.
2. where appropriate adjustments on historical data are not feasible, institutions should consider these circumstances by a larger margin of conservatism in the estimation of risk parameters and final impact.
    

It is important that the total portfolio exposure is equal between in both views.

Additional attention points must be taken into consideration in the obligor base program, like for instance, joint-obligor segment definition or how will the obligor base be incremented/refreshed daily with new entries, or duplicates records avoidance, etc. We can help you cope with those aspects.

The obligor base program is run retro-actively on the historical daily snapshots of the portfolio that the institution has at its disposal as well as on all newly collected daily data within the defined observation horizon.
 

Regarding the exposure and the unpaid amount at obligor level, the calculation, at a given date, is done as follows: 

• The on-balance exposure of the obligor is equal to the sum of the on-balance exposures of all credit obligations linked with that obligor;
• The past due amount of the obligor is equal to the sum of past due amounts on all credit obligations of the linked with the obligor.

This calculation is performed retro-actively on the historical daily snapshots of the portfolio that the institution has at its disposal as well as on all newly collected daily data within the defined observation horizon.
 

Regarding the materiality thresholds calculation and DPD counting, both are based on the information collected at a given date regarding the obligor total unpaid amount and the obligor total on-balance exposure.

As mentioned, in some situations, described in the EBA guidelines, the contagion doesn’t apply automatically but requires a case by case assessment. More details are available in the EBA Guidelines, paragraphs: 99, 100 & 105.

The next step will be to start from that initial date; you will run your programs to all next historical daily images of the portfolio in order to:

• update your obligor base;
• update the status of past dues in comparison to materiality thresholds;
• update the situation of UTP indications;
• update any new contagion to be applied based on the portfolio evolution;
• update the situation of obligors in probation period.

At the end of the exercise you qauire your evolving daily history of default/sound obligors and contracts for the whole observation period that you’ve initially fixed.

That will form the fundamental dataset you will need to perform further analysis such as transition matrix, 1year DR, impact on default portfolio in amount and number of obligors, impact on PD & LGD, cure rate, on provisions, on RWA and on capital charges. We can help you in performing such analysis.

What if you do not dispose of historical daily snapshots or not enough to perform a quantitative impact assessment?

A closer workaround solution to daily images are the monthly images. However, such should be treated with a sufficient dose of conservatism, as monthly views have several disadvantages like ignoring any entry or exit from default between two monthly snapshots due to past due or UTP.
It is important all assumptions/workaround scenarios to be approved beforehand knowing their impact on your simulation results.
 

A retrospective simulation of the new definition of default on data is an interesting tool for predicting the true impact of the new regulation and better anticipate any consequent capital charges. An important prerequisite to this exercise is to have a clear and correct understanding and interpretation of the rules prescribed by EBA Guidelines on the application of the default definition and by the RTS on materiality threshold of past due credit obligations. 

It’s true that such exercise requires a significant effort from the bank teams in addition to the effort already engaged in implementing the new default rules in IT systems, internal policies and processes. However, this effort offers you an additional mean to assess whether new definition of default is correctly applied in the systems or not by comparing the two outputs (system based and data based); and therefore will give more comfort in validating further deployment in production.