Extending the previous post, the interesting problems occur when there is interplay between the two dimensions of the default definition, namely time (DPD) and amount (material credit obligation in dollars). This discussion segues into the “re-aging” issue which is complex AWML.

Many default cases will thankfully (?) be simple: as long as it is one-way traffic, the analytical aspects are not controversial. The simplest case is:

  • an account goes past due on some material credit obligation at a certain date, and the DPD counter starts ticking.
  • the account holder never reduces the original credit obligation below the materiality threshold
  • DPD counts steadily upwards until it triggers the default definition at 90 or 120 (or whatever) DPD

Typical cases are that an account holder stops making any kind of payment on some standard retail product (CC, PL) that requires a payment each month. The account then rolls through the successive default categories 30,60,90,..DPD and into collections, recoveries, write-off.

The potentially difficult cases are those involving interplay between time and amount, i.e. the amount of the credit obligation varies across time, including the possibility that it dips in and out of materiality thresholds. These would be cases where the account holder makes some partial repayments. Accounting issues then arise, with partial payments being applied firstly towards reducing the oldest outstanding amounts. For example, at 75DPD there might be a payment that was sufficient to settle the oldest amount outstanding, but not quite sufficient to settle the 45-day old amount, although enough to reduce that 45-day amount to below the materiality threshold. Where does that leave the DPD counter and the default definition? 

Can readers with accounting knowledge confirm that it is not difficult in principle to track the outstandings in 30-day buckets (i.e. how much is due, 30DPD, 60DPD, 90DPD, .. etc.) and to adjust these as partial payments come in. The problem I experienced as a modeller, though, was that in the historic summary data these bucketings of the outstanding obligation are not always separately available - only the total amount outstanding - and so it was not possible to re-create the intended default definition.

For CC, due to the varying monthly payment requirements, these buckets are usually available, but one has to accept them as given and it would not be possible (for example) to re-work them with a different materiality.

For products with a fixed monthly instalment and a standard amortisation schedule, one approach taken was to convert the amount outstanding - i.e. the amount by which the balance exceeds its amortisation schedule - into an equivalent number of months (or days) by dividing by the monthly instalment. For example, an account that is $2500 over, with a monthly installment of $1000, is 2.5NMA ~=75DPD. Note that under this definition it’s not impossible for this situation to come about in less than 75 days, i.e. an account might go from 0DPD to 75DPD in one day. By contrast, an account might pay nothing at all for a year without going past due, if it had previously paid down the balance to be well below the schedule. These comments naturally depend on the product rules and practices in place.

A general issue in all this is the difference between a definition of “default at a particular point in time”, and the longitudinal consideration of “default episodes” that have a time dimension, i.e. a certain account went into default at time x and stayed in default until time y. This does not have to be the same as saying that the account was in default at every point in time between x and y. This introduces the re-aging issue AWML.

Beneath all this, the time granularity of the data is playing a big part, and the above issues are addressed mainly on the assumption of monthly granularity. Daily granularity would accentuate the issues and probably produce some new tricky issues. With quarterly or longer granularity, many of the issues would disappear or be trite.  

Possibly related posts: (automatically generated)