The best time to act on a deteriorating loan is before it goes late. A missed payment only confirms what the account has been telling you for weeks. An early-warning system reads the behaviour that precedes the miss and flags the account while a call or a limit change can still alter the outcome.
Most lenders already have the raw material. Transaction histories, repayment records, limit utilisation, and whatever external data they pull at origination usually keep flowing after the loan is booked. The problem is that nobody is reading it as a time series. The account gets underwritten once, then sits until it breaks. Early warning is the discipline of turning that dormant post-origination data into a monitored, dated stream and scoring it on a schedule.
What actually moves before a loan goes bad
The signals that matter are rarely dramatic. They are small changes in behaviour that show up weeks before the account misses. In our work, the features that carry the most weight fall into a few groups.
- Payment behaviour: a payment that lands three days later each month, a switch from paying in full to paying the minimum, a first partial payment, or a direct debit that gets cancelled and re-set at a lower amount.
- Balance and utilisation dynamics: revolving utilisation creeping past 80 and staying there, a deposit balance that no longer rebuilds between paydays, or a current account that starts touching its overdraft limit at month-end.
- Cash-flow shape, where you have transaction access: falling inflows, a lengthening gap between receivables and payables for a business borrower, or salary credits that stop arriving on their usual date.
- External events: a new adverse filing, a downgrade or default on a related entity, a director change, or a county court judgment against a linked company.
The trick is not finding these features. It is dating them correctly. Every feature has to be built as of a point in time, using only what you would actually have known on that date. A utilisation figure that quietly includes end-of-month settlement, or an external filing timestamped by when you ingested it rather than when it became public, will look brilliant in backtest and useless in production. That gap is lookahead leakage, and it is the single most common reason early-warning models fail the moment they go live.
Building features you can trust in production
Point-in-time correctness is the whole game here, so it is worth being concrete about what it demands.
Start with lineage. Every feature needs to trace back to a source record and an effective date, not only to a value. When an analyst asks why an account fired last Tuesday, you should be able to show the exact transactions and filings that drove the score, with the timestamps you held at scoring time. This is also what a model-risk reviewer will ask for under an SR 11-7 style validation, and what a regulated lender needs to defend a decision that affected a borrower.
Entity resolution comes next and gets underrated. A single borrower shows up across current accounts, cards, and loans under slightly different identifiers, and a business borrower connects to directors, guarantors, and sister companies. If your external adverse-event feed keys on a registration number your loan book does not store cleanly, the signal never reaches the right account. We spend real effort on reconciliation between the servicing system, the transaction feed, and any bureau or registry data, because a signal that lands on the wrong entity is worse than no signal.
Then there is the boring but decisive work of a feature store that recomputes on the same cadence you score. If the model was trained on features built one way in an offline pipeline and served features built another way in production, you get training-serving skew, and the model’s behaviour drifts away from its evaluation the day it ships. Build the two paths from one definition.
A few habits keep the system honest over time:
- Freeze an out-of-time evaluation set from a period the model never saw during training, and judge every candidate against it. In-time cross-validation flatters early-warning models badly.
- Monitor feature drift and population stability alongside model accuracy. A borrower base shifts, a data feed changes format, a quarter-end reporting quirk appears, and the score degrades silently unless you are watching the inputs.
- Version the feature definitions alongside the model, so a change to how utilisation is computed is a tracked event and not a mystery.
Turning scores into action people trust
A score on its own changes nothing. The harder half of the project is deciding what happens when an account crosses a threshold, and making sure the people downstream believe the flag.
Choose the event you predict deliberately. Predicting charge-off is easy to label and nearly useless, because by the time it happens the money is gone. We usually target the transition into early delinquency, or a covenant heading toward breach, because those come with a window in which a call or a restructuring offer still changes the outcome.
Set a false-positive budget before you tune anything. If a relationship manager can work fifteen cases a day and you send them sixty, they stop reading the alerts within a week and the whole system quietly dies. Calibrate thresholds to the capacity of whoever acts on the flag, and add suppression rules so the same account does not fire every day it stays elevated. Some interventions can run straight-through, such as an automatic hardship offer or a soft limit hold. The higher-severity cases route to a human with the evidence attached.
Keep the audit trail from score to action. For each flag, store the features that drove it, the threshold in force that day, who reviewed it, and what they did. That record is what lets you measure whether the early warning actually improved outcomes versus the accounts you did not touch, and it is what you hand a validator or a regulator when they ask how a borrower came to be treated the way they were. Without it you have a model that fires and no way to prove it earned its place.
FAQ
How far ahead can early-warning signals realistically detect deterioration?
For unsecured consumer books, useful lead time is usually 30 to 90 days before a missed payment; for SME lending it can stretch to a quarter or two because filings, receivables and cash movement turn slowly. Anything claiming six months of clean lead time on a monthly-reporting borrower is usually leaking future data into the features.
Should early-warning models predict default or something earlier?
Predict the intervention-worthy event, not the terminal one. A model that flags the transition into 30 days past due, or a covenant breach, gives you a window to act; a model tuned only on charge-off tells you what you already know too late to change.
How do you keep an early-warning system from drowning analysts in alerts?
Set an explicit false-positive budget tied to how many cases a reviewer can work per day, then calibrate thresholds and suppression rules against that number rather than against a raw accuracy score. Alerts that never change a decision should be tuned out.