Expected credit loss modelling under IFRS 9 sits at the intersection of accounting, credit risk and statistics. Since the standard took effect in 2018, most banks have built ECL frameworks on traditional techniques: logistic regression for probability of default, historical averages or regression for loss given default, and satellite models linking risk parameters to macroeconomic variables.
These approaches are well understood by auditors and regulators, and they remain entirely appropriate for many portfolios. But they also have limitations that have become more visible since the standard was introduced, particularly in how quickly they respond to changing conditions, and in how much they rely on management overlays when the unexpected happens.
Machine learning offers genuine advantages in several parts of the ECL process. It also introduces new challenges around explainability, stability and governance. This article sets out where machine learning adds value in ECL, how we design the architecture, and what it takes to satisfy auditors and supervisors.
A brief refresher on the ECL framework
IFRS 9 requires entities to recognise a loss allowance for expected credit losses on financial assets measured at amortised cost and at fair value through other comprehensive income, as well as on certain loan commitments and financial guarantees. The core mechanics are:
- Staging. Exposures are allocated to Stage 1 (12-month ECL), Stage 2 (lifetime ECL, following a significant increase in credit risk since initial recognition) or Stage 3 (lifetime ECL, credit-impaired).
- Risk parameters. ECL is typically calculated from probability of default (PD), loss given default (LGD) and exposure at default (EAD), estimated over the relevant horizon.
- Forward-looking information. Estimates must reflect reasonable and supportable forecasts of future economic conditions, usually through multiple weighted macroeconomic scenarios.
Each of these elements involves significant judgement, and each is a candidate for improvement through better modelling.
Where machine learning adds value
Probability of default
PD modelling is the most established application of machine learning in credit risk. Gradient-boosted tree models, in particular, often outperform logistic regression in discriminatory power because they capture non-linear relationships and interactions between variables without those relationships needing to be specified in advance.
The gains are typically greatest in portfolios with rich behavioural data (retail credit cards, current accounts, consumer loans) where transaction patterns, balance trends and payment behaviour carry signals that linear models struggle to exploit.
Significant increase in credit risk
Stage 2 allocation is one of the most judgemental areas of IFRS 9. Many banks rely heavily on the 30 days past due backstop and simple PD-change thresholds, which tend to identify deterioration late. Machine learning models trained to predict future deterioration can identify at-risk exposures earlier, improving the timeliness of Stage 2 transfers, an area where supervisors have repeatedly pressed banks to improve.
Loss given default
LGD is notoriously difficult to model because recovery data is sparse, workout periods are long and outcomes are often bimodal: most defaults either recover fully or lose heavily. Machine learning techniques can better capture the drivers of recovery, particularly for secured lending, where collateral characteristics, loan-to-value dynamics and borrower behaviour interact in complex ways.
Forward-looking macroeconomic linkage
Linking risk parameters to macroeconomic scenarios is where many ECL models are weakest. Traditional satellite models often rely on a small number of variables selected through regression, with relationships estimated over limited historical periods. Machine learning can explore a wider set of candidate variables and relationships, though this is also the area where the risk of overfitting is greatest, and where the case for constrained, interpretable approaches is strongest.
Designing the architecture
A production-grade ML-based ECL framework needs more than a better model. It needs an architecture that supports governance, reproducibility and auditability from the start. The design we use has five layers.
1. Governed data foundation
All modelling data (obligor, facility, collateral, behavioural, default and recovery history, and macroeconomic series) is sourced from governed, reconciled data sets with documented lineage. Features are defined once in a feature store and reused consistently across development, validation and production.
2. Model development environment
Models are developed in a controlled environment with version-controlled code, fixed random seeds, recorded training data snapshots and experiment tracking. Any model result must be exactly reproducible from its recorded inputs.
3. Challenger framework
Every machine learning model is developed alongside an interpretable benchmark, typically a well-specified logistic regression or scorecard. The ML model must demonstrate a meaningful improvement over the benchmark to justify its additional complexity, and the benchmark remains available as a fallback.
4. Explainability layer
For every prediction, the framework produces an explanation of the main contributing factors, typically using SHAP values. At portfolio level, explanations are aggregated to show which drivers are moving ECL between periods. This layer is essential for model validation, audit, and management's own understanding of the results.
5. Monitoring and controls
In production, the framework monitors data drift, population stability, discriminatory power and calibration, with defined thresholds that trigger investigation or recalibration. Model outputs pass through the same reconciliation and approval controls as any other input to the financial statements.
A model that cannot be explained cannot be governed, and in financial reporting, a model that cannot be governed cannot be used.
Governance and model risk management
Machine learning does not change the fundamental expectations of model risk management; it raises the bar for meeting them. Supervisors across many jurisdictions expect banks to apply their model risk frameworks to ML models with particular attention to explainability, bias, stability and the adequacy of validation.
In practice, the governance requirements we build into ML-based ECL programmes include:
- Clear documentation of the model's purpose, methodology, data, assumptions, limitations and intended use, written for a knowledgeable reader who was not involved in development.
- Independent validation by a team with the technical skills to challenge machine learning techniques, including hyperparameter choices, feature selection and the risk of overfitting.
- Conceptual soundness testing to confirm that the model's behaviour makes economic sense: for example, that PD increases as affordability deteriorates, and that relationships with macroeconomic variables have the expected direction.
- Stability testing across time periods and sub-populations, to confirm that performance is not dependent on a particular sample.
- Fairness review where models use customer data, to identify and address unintended bias.
- Defined overlay governance, so that where management adjusts model output, the reasons are documented and the adjustment is removed once the model captures the effect.
Audit considerations
External auditors approach ML-based ECL models with appropriate scepticism, and preparing for the audit is part of the design, not an afterthought. The questions we consistently see, and design for, include:
- How was the model selected over simpler alternatives, and what evidence supports the choice?
- Can the model's outputs be reproduced from recorded inputs?
- How are individual predictions and period-on-period movements explained?
- How does the model respond to the forward-looking scenarios, and is that response reasonable?
- What monitoring is in place, and what happens when thresholds are breached?
- How are overlays governed, and how large are they relative to modelled ECL?
Auditors will often engage their own modelling specialists. Providing well-structured documentation, reproducible code and clear explanation outputs significantly reduces the time and cost of the audit, and the risk of late surprises.
Practical lessons from implementation
From the ML-based ECL work we have delivered, several practical lessons stand out:
- Start with one portfolio. Choose a data-rich retail portfolio where the benefit is likely to be greatest, and use it to build the architecture, governance and validation approach before extending to others.
- Keep the benchmark. A strong interpretable benchmark model is invaluable for validation, for explaining results and as a fallback if the ML model needs to be withdrawn.
- Constrain the model where economics demands it. Monotonic constraints, which force a relationship to move in only one direction, are available in modern gradient-boosting libraries and can prevent economically implausible behaviour.
- Invest in explanation outputs early. Finance and credit committees need to understand why ECL moved. Explanation outputs designed for them, not only for data scientists, make adoption far easier.
- Plan for model monitoring from day one. ML models can degrade quietly as populations and conditions change. Automated monitoring is essential, not optional.
The right tool for the right problem
Machine learning will not replace traditional credit risk modelling across every portfolio, and nor should it. For low-default portfolios, specialised lending and exposures with limited data, expert-led and simpler statistical approaches remain the right choice.
But for high-volume, data-rich portfolios, machine learning can deliver more accurate risk differentiation, earlier identification of deterioration and a clearer understanding of what drives credit losses. When built on sound architecture and governed properly, it can reduce reliance on overlays and give management greater confidence in one of the most significant estimates in a bank's financial statements.
Our AI and IFRS practices work together on ECL engagements, combining modelling expertise with a deep understanding of the accounting requirements and audit expectations. That combination, in our experience, is what turns a promising model into one that can actually be used.