2
$\begingroup$

I edited my post for clarity, for the second time. Thx lpounng for the feedback.

I am seeking advice on predicting debt payment within a year. Each debt has its own carachteristic wich are not easy to aggregate.

Moreover, multiple debts can correspond to the same debtor, and it is common for a debtor to fail to pay multiple debts. So If I tried to calculate the probability of payment for individual debts and multiply them to get the probability of payment for all debts of a debtor I would be wrong because the debts are not independent (Bayes).

I suspect that, when the time comes to predict a new value, to predict payment for a new debtor, I need to have information about all of their debts at the time. This leads me to construct a register where all information about debts for a debtor needs to be contained... so how could I go about it? I don´t see possible to make a column for each feature for each of the n possible debts per debtor (i.e. "amount paid debt 1", "amount paid debt 2", ... , "amount paid debt n".) because of NA values that would populate most columns and that I can´t know n in advance (maybe a new debtor arrives with n+1 debts... and how would I go about imputing values for that load of variables). On the other hand if I aggregate the amount paid for every debt I would loose information (not that much in this feature... but think more of number of installments paid... which would be kind of heterogeneous when summed up... like summing apples and bananas).

So... is it possible to use as features the individual debts fields or I should make a model doing feature engineering predictors that summarise total debt carachteristics?

Thank you

Improve this question
$\endgroup$
2
  • 1
    $\begingroup$ I read the post 2 times and still not getting what OP is asking for - the title does not match the body, objective not well defined, and multiple questions are raised. My advice is to take a step back, clear up your mind on what the objective is first $\endgroup$
    – lpounng
    Commented Feb 23, 2023 at 3:05
  • $\begingroup$ Thank you lpounng for your feedback and your time. $\endgroup$
    – Mauro Crosignani
    Commented Feb 23, 2023 at 12:14

1 Answer 1

Reset to default
1
$\begingroup$

The most straightforward approach is, I think, to engineer features per customer. To your "sum number of installments paid", something like "average percent of installments paid" might fix the heterogeneity.

In the extreme/limiting case where each customer either repays or defaults on all debts, you have a "multiple instance learning" problem. The wikipedia article for that subject might give some inspiration for ways to adapt to this setting.

Improve this answer
$\endgroup$
4
  • $\begingroup$ I think that this algorithm also solves an additional level of difficulty, which I was planning to tackle if I found a way to solve the problem in its most basic form. It also manages to classify debtors based on a threshold. $\endgroup$
    – Mauro Crosignani
    Commented Feb 23, 2023 at 14:07
  • $\begingroup$ Once red, I have doubts about it because I can label every individual debt, but the Wikipedia article says 'in multiple-instance learning, the training set consists of labeled “bags”, each of which is a collection of unlabeled instances'. As I have labels for each instance, I´ll have to play a little with that to confirm if this is the answer. $\endgroup$
    – Mauro Crosignani
    Commented Feb 23, 2023 at 14:31
  • 1
    $\begingroup$ @MauroCrosignani your problem absolutely isn't a multiple-instance learning one. That's why I said "in the extreme case" and "some inspiration". One of the approaches discussed (at the end of the "Instance-based algorithms" section) tries to build instance-level "concepts" to finally use in an ordinary bag-level classification, and I think here you can get something even nicer: the concepts can get information from your instance-level labels. The question (to me) is how exactly to handle the bias in instance-level labels: at the instance level, or only later at the bag level? $\endgroup$
    – Ben Reiniger ♦
    Commented Feb 23, 2023 at 15:20
  • $\begingroup$ I´m not sure if this general paradigm applies to my problem because instances in MIL are not dependent on one another. As I interpret this, the bias is two-fold, from one instance to the next and from the customer to each instance. But I consider that feature engineering per customer would resolve most of my problems so I would go with your first suggestion. I guess this is why financial corporations apply a credit score, maybe I could look into that. $\endgroup$
    – Mauro Crosignani
    Commented Feb 24, 2023 at 14:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.