The credit restructuring process is the single most important process that can be applied to a contemporary credit portfolio, when only our main prior is customer’s rehabilitation.
The process itself is simple, linear, and uniform across portfolio segments. Its implementation details, however, can get quite complicated, especially when they come into conflict with the established practices and systems.
In this article, we focus on the system quirks and data curiosities, that based on our experience, can appear during the whole process. According to our large number of portfolio datasets, there is a wide range of recurrent system quirks one may encounter.
Recording offers and terms
Operational systems may not record offer and terms in a way that can be used for analytics. Unsuccessful offers may not be recorded on the system. Thus, there is no guarantee that a full offer history will be maintained (it is not unheard of for the latest offer to overwrite earlier ones). Companies should make an effort to validate the scope of the information available.
Credit facility modifications, old and new accounts
Depending on the type of restructuring, an account may be modified “in place” or replaced by a new account. This new account may reside in the same system or in a different one, and the two systems may not even be aware of each other. More than one account may be subject to the same restructuring process, and may result in a single, merged new account after the restructuring. It is important to be careful over the transition to ensure all data is available and models are effective.
Other data curiosities
There are four common occurrences that originate in the handling of the restructuring process. The following examples are not exhaustive but act as a warning about the never-ending surprises lurking within portfolio management systems – no matter how well-designed and managed.
When working with credit portfolios the transactions of interest are customer payments. Unfortunately, in some cases is not easy to distinguish between those and other transactions.
It is important to clarify systems’ and portfolios’ rules on balance transfers transactions. If they are indistinguishable from other payments, it is critical to set up commonly accepted business rules, on which transactions are to be designated as such.
This problem can require surprisingly complicated business rules to resolve. Thus implementing them consistently, requires to embed them in a common data warehousing and transformation infrastructure.
These occur when there is no consistency on when the original, non-restructured account is closed. For example where the account closure requires manual approval.
Some systems may contain multiple, independent views of the portfolio they are managing. These should be automatically synchronised at all times, but problems will arise if, for any reason, they are not. This may happen, for example, if there is a delay in allocating payments received to the accounts they are repaying.
More than one account may result from a restructuring. This could be to isolate a part of the customer’s debt that will be conditionally written off, or renegotiated, after the current agreement has been repaid. It is important to identify which is the actual restructured account to be monitored, and to decide what to do with the “balloon” account.
