Predict which alerts will be escalated
A monitoring unit receives automated alerts built from customers' transaction history. Specialists either dismiss each alert or escalate it. For every alert in a hidden test set, we predict the probability of escalation. The data is synthetic and contains no real customer records.
Input
A list of alerts with their date and outcome, plus every transaction behind each alert: time, direction (in / out), type (card, bank transfer, cash, international) and a standardised amount.
Metric: ROC-AUC
Measures ranking only: how often a random escalated alert gets a higher score than a random dismissed one. 0.5 is a coin flip, 1.0 is perfect.
Deliverables
A prediction file (signal_id,ehtimollik), this EDA website, and a reproducible notebook.
Explore
Check quality, then test concrete questions against the data.
Summarise
Turn each alert's ~500 transactions into one row of statistics.
Model
Tune three gradient-boosting models and keep the best.
Validate
Cross-validation, plus a final check on the newest alerts, held back from the start.
Two linked tables, about 1 in 6 alerts escalated
Each alert links to its transactions by signal_id, covering the 180 days before the alert. The data is clean: no missing values, no duplicates, and no transaction shared between alerts.
- signal_id · key
- signal_sanasi · alert date
- eskalatsiya · target 0/1
- signal_id · link to alert
- tranzaksiya_vaqti · timestamp
- kirim_chiqim · in / out
- tranzaksiya_turi · type
- miqdor_indeksi · amount
Target distribution
Escalation rate by month
What a typical history looks like
Cards (54%) and bank transfers (39%) dominate. Three of every four transactions are incoming. Cash and international transfers are rare.
Transaction type × direction
Activity before the alert
Three things the data told us
To score a single statistic we use its separation, |AUC − 0.5|: 0 means it can't tell the classes apart, and higher is better.
Whole history beats recent activity
Separation grows with the lookback window, so short-term "velocity" features were dropped.
Bank transfers carry the signal
Escalated alerts lean toward smaller bank transfers. Other types barely differ on their own.
Contrasts beat levels
Comparing a type with the customer's own overall level roughly doubles separation. This was the biggest win.
Longer history separates better
Level vs contrast, per type
Bank transfer sizes: escalated vs dismissed
From findings to features
Each finding became a feature group: 470 candidate features in total. Tuning picked the best 40, and 70% of those are contrasts.
Contrasts
Each type vs the customer's own level, type vs type (e.g. bank minus cash), incoming vs outgoing. From finding 3.
Distribution shape
Mean, spread, skewness, min/max and quantiles, computed per type and direction. From finding 2.
Counts & shares
How many transactions of each type, so the model knows when a statistic rests on only a few.
Three tuned models
Most useful features
bank_m_kart_q95large bank transfers vs large card paymentsbank_m_naqd_q75bank transfers vs cashkart_minsmallest card paymentkart_q99_rellargest card payments vs the customer's own levelown_minsmallest transaction overall
Tried and dropped
- Short-term velocity and burst featuresno gain
- Night / weekend activity, money in → quickly outno gain
- Neural networks over the raw transaction sequenceworse (0.581)
- Averaging the three models+0.002, noise
- Probability calibrationcan't raise AUC
What we learned
- The data is clean and leak-free, with a stable 17% escalation rate over time.
- One transaction says almost nothing. The signal appears only when the full 180-day history is summarised; recent bursts don't help.
- How a customer's bank transfers compare with their other activity matters more than any absolute amount.
- A tuned XGBoost on 40 contrast-heavy features reaches ROC-AUC 0.660 in cross-validation and 0.689 on the newest held-back alerts.