🏢 The situation
Datacore's fintech arm is launching installment payments. It needs scoring: approve the application or not. Igor hands you the feature preparation:
"The model will be simple; the features are where quality is won. The industry rule: the best model on weak features loses to a simple model on strong features. You have three tables: applications, wallet transaction history, and past installment history. Build the feature matrix from them. And be careful with categories and missing values — in production applications arrive messy."
🎯 Your task
- Master aggregate features from transaction history.
- Encode categorical features correctly.
- Handle missing values so it works in production too.
📚 Theory
What feature engineering is
Transforming raw data into features that "highlight" the task for the model. Kinds:
- Aggregates over history: sums, means, counts, shares over time windows (30/90/180 days).
- Ratios and differences: payment / income, days since last delinquency.
- Temporal features: day of week, account age, seasonality.
- Categorical encoding — turning strings into numbers.
- Transformations: log for skewed amounts, age binning.
Encoding categorical features
| Method | How | When |
|---|---|---|
| One-Hot | a column per category | few categories (< 15–20) |
| Ordinal | category → number | categories truly ordered (education) |
| Target encoding | category → mean target within it | many categories; ⚠️ leakage risk — compute on train only, with CV/smoothing |
| Frequency | category → its frequency | fast and often surprisingly good |
⚠️ Trap: one-hot for "city" with 900 values → 900 columns, a sparse matrix, overfitting to rare cities.
Missing values: think like a production engineer
- Fill with statistics computed on train (otherwise leakage).
- A missingness flag as a separate column is often useful: "didn't state income" is itself a risk signal.
- In production a category/value unseen in training will arrive — the pipeline must survive it (
handle_unknown="ignore", defaults).
Feature leakage (the main enemy of scoring)
A feature must not contain information from the future relative to the application moment. A classic failure: the feature "number of debt collector calls" — it only appears for those already delinquent. A model with it shows a fantastic AUC on history and collapses in production. The rule: all features are computed strictly on data available before the application moment (point-in-time).