Adjusting the existing IT systems to accommodate the default triggers imposed by the new definition is quite challenging and resource consuming. The success depends on:
- A common and precise understanding of the “to be” situation for all involved parties: Functional and Technical stakeholders;
- Access to expert business analysts able to translate complex regulatory requirements into functional/technical specifications towards systems or models and to figure out future impacts.
- The manner the changes are conducted: in a project mode, involving multi-disciplinary teams:
- Risk and Finance functions use a large amount of common data, among which the default concept. Moreover, they are part of the end to end Regulatory Reporting process and any change in the default definition will impact both. Besides, some of the processes specific to them are directly linked with the default definition, for instance, estimation and validation of the Risk parameters (PD & LGD) by the Risk function, classification of credit exposures or calculation of credit loss allowances within Finance/Accounting functions.
- Whilst developing the lending strategy, the business department takes into account the input from the Risk management function regarding the development of the credit portfolios and the risk-related indicators on customers at risk of default or already in default.
- Any change in the scope of criteria of classification in default would imply a need to adapt the Collection unit’s recovery procedures accordingly.
- The IT department is significantly impacted both on system and data aspects, as the new definition of default will require enhancing core operational systems that deal with default detection as well as other satellite systems linked, like provisioning tool or reporting tools. The database will require a serious upgrade in terms of capacity in order to be able to manage the storage of daily images of credit portfolios and past due information.
- This list is by no means exhaustive, as a number of other departments may be affected too.
In a nutshell, some of the most significant changes that IT systems would need to implement are:
Automation: the systems must allow a timely identification and automated channelling of the information on default triggers in order to treat the relevant exposure and operate the default classification of the exposure / obligor in time. The same applies for the return to non-default status.
Daily treatment of indications of default: both regarding counting the days past due and signs of Unlikeliness to Pay. Some institutions have a daily identification and follow-up of default triggers, but the flagging of the exposures as defaulted happens on the monthly basis. In some other institutions, contagion does not happen on a daily basis.
Where default is applied at obligor level, consistent obligor identification and in particular “Joint obligors” identification: the system should allow identifying a “joint obligor” as a specific set of individual obligors that have a joint obligation. The system should treat it as a different obligor, distinct from the individual obligors. This point is crucial for the correct application of materiality thresholds on joint credit obligations as well as for default contagion.
Materiality thresholds for days past due counting: with the NDoD, systems should integrate an additional condition to trigger the counting of days past due, i.e. the exceeding of both absolute and relative thresholds. This implies the ability of the system to:
- properly value the past due amount of an obligation;
- properly value the total on-balance exposure of an obligor especially in the cases of joint obligors.
Depending on the current usage (Total or partial) of materiality thresholds, the impact from their implementation will vary. Some institutions use only absolute or only relative, some others use both (with an ‘and’ or ‘or’ clause). Besides, some institutions currently have higher and some lower thresholds. All these aspects will pre-determine the impact, depending on whether the currently applied approach is more or less conservative than in the new GL.
For institutions that decide to apply the definition of default for Retail exposures at the obligor level, the system should be parameterized to properly apply contagion between the exposures of a single obligor but also specific contagion rules for joint credit obligations.
A key success factor for the last three points is the proper identification of obligors (single / joint).
There are other technical changes in the systems that are also necessary but may be less complicated to implement because they resemble other challenges that the banks are already familiar with.
- The minimum probation period of 3 months before coming back to non-defaulted status. The banks already apply a similar mechanism for forborne exposures which are kept in default 12 months before assessing their eligibility to exit from defaulted status.
- The technical past dues: systems can easily identify situations of payments made before 90 days but with an account crediting having occurred after the 90 days past due. On the other hand, this specific situation may be difficult to apply retroactively on historical data, for example in a database.