IFRS 9 and expected credit loss modelling

Study purpose

This chapter is written as a serious banking study guide, not a technology brochure. The aim is to explain ifrs 9 and expected credit loss modelling in a way that a business analyst, architect, developer, tester, risk specialist, operations lead, compliance reviewer or student can use inside a real bank. The discussion stays close to banking decisions, data, controls, customer impact, model governance and audit evidence.

The chapter also explains how this topic connects to AI and machine learning without pretending that every banking problem should be solved by AI. Some questions need deterministic rules. Some need scorecards. Some need statistical models. Some need human judgement. The practical skill is knowing which method belongs where, and how the evidence travels from source data to final bank action.

How to study this chapter

IFRS 9 expected credit loss modelling is one of the clearest examples of banking data, accounting, risk and modelling becoming one joined story. It is not only a finance calculation. It requires credit risk signals, historical performance, current conditions, forward-looking information, model governance, management judgement and audit evidence.

In practical banking terms, this means the bank must identify the decision point, the data available at that moment, the control owner, the allowed action, the expected customer or regulatory impact and the evidence that will be stored afterwards. A model output becomes useful only when it changes a real workflow in a controlled way. If the output cannot be tied to an action, a user, a policy rule, a monitoring metric and an audit trail, it is not yet production-grade banking AI.

For delivery teams, the safest approach is to describe the use case as a chain: source event, data validation, feature or rule calculation, model or score output, policy orchestration, human review where needed, customer or operational action, reporting and feedback. This keeps the project grounded. It also prevents the common mistake of discussing AI as if it floats above the bank instead of sitting inside payment hubs, credit platforms, risk engines, case tools, ledgers, data warehouses and monitoring dashboards.

What changed with IFRS 9

The old incurred-loss mindset recognised losses after evidence of impairment appeared. IFRS 9 introduced a forward-looking expected credit loss approach. Banks need to recognise expected losses earlier by considering past events, current conditions and reasonable supportable forecasts.

Why AI and ML matter here

Expected credit loss modelling depends on estimating risk over time. Models may estimate probability of default, loss given default, exposure at default, staging movement, macro sensitivity and portfolio segmentation. Machine learning can support parts of this work, but accounting outcomes require governance and explainability.

Stage 1 in plain language

Stage 1 generally represents performing assets without significant increase in credit risk since initial recognition. The bank recognises 12-month expected credit losses. This does not mean the bank expects default within exactly twelve months; it measures expected loss from default events possible within that horizon.

Stage 2 in plain language

Stage 2 represents assets where credit risk has increased significantly since initial recognition, but the asset is not credit-impaired. The bank recognises lifetime expected credit losses. Movement into Stage 2 can materially increase provisions, so staging logic must be controlled.

Stage 3 in plain language

Stage 3 represents credit-impaired assets. The bank recognises lifetime expected credit losses and interest revenue treatment changes according to the accounting requirements. For operational teams, Stage 3 usually aligns with default, impairment or serious credit deterioration concepts.

Significant increase in credit risk

SICR is a critical judgement area. The bank may use relative PD movement, absolute PD thresholds, days past due backstops, forbearance indicators, watchlist status, restructuring, adverse behaviour or other credit deterioration signals. The logic must be documented and monitored.

PD in ECL

Probability of default estimates the likelihood that a borrower will default over a defined horizon. IFRS 9 modelling may require 12-month and lifetime PD views. The model must be point-in-time enough to reflect current and forward-looking conditions rather than only long-run averages.

LGD in ECL

Loss given default estimates how much the bank expects to lose if default occurs, considering collateral, recoveries, costs, seniority, cure, time to recovery and economic conditions. LGD is not merely the unpaid balance. It is a loss expectation under default conditions.

EAD in ECL

Exposure at default estimates the balance the bank expects to be exposed to when default happens. For term loans this may be straightforward. For cards, overdrafts and revolving credit, future drawings and credit conversion behaviour can make EAD more complex.

Forward-looking scenarios

IFRS 9 requires forward-looking information. Banks often use macroeconomic scenarios such as base, upside and downside views with probability weights. Variables can include unemployment, GDP, interest rates, property prices, inflation or sector indicators depending on the portfolio.

Management overlays

Models cannot capture everything. Banks may apply management overlays when model outputs do not fully reflect emerging risk, data limitations, macro uncertainty, temporary programmes or portfolio changes. Overlays must be evidenced, approved, monitored and released when no longer needed.

Data quality

ECL models depend on default history, exposure data, collateral data, recoveries, write-offs, cures, product types, origination dates, risk grades, behavioural indicators and macro series. Weak source data can distort provisions and create audit issues.

AI risks

Machine learning can improve segmentation or risk prediction, but IFRS 9 outputs must be explainable enough for finance, audit, risk and regulators. A model that improves a metric but cannot support provision governance may not be suitable for accounting use.

Business analyst role

The BA must map accounting requirements into data and process: staging trigger, source field, risk model, approval workflow, adjustment process, audit report, reconciliation and governance owner. IFRS 9 work fails when finance, risk and technology use the same word differently.

The main lesson

IFRS 9 made expected loss recognition more forward-looking. AI can support risk insight, but the bank must defend every material assumption, data source, model output, overlay and reporting number.

Chapter-level control checklist

Business analyst study prompts

• Draw the process before and after the model is introduced. Mark exactly where the bank decision changes.
• List the deterministic controls that must remain outside model discretion.
• Identify which source systems provide the data and whether the data is available before the decision.
• Write the reason a user would trust, challenge or override the output.
• Define the customer impact if the model is wrong in both directions.
• Describe what operations, risk, compliance, finance and technology each need to see.
• Explain what would happen if the model service is unavailable during a peak period.
• Define the monitoring report that proves the use case is still safe after go-live.

Main lesson

IFRS 9 made credit loss modelling more forward-looking, forcing banks to connect accounting, risk models, data quality and governance. The best banks will not adopt AI by replacing every existing rule, scorecard or control. They will adopt AI by understanding where learning systems improve judgement, where deterministic rules remain stronger, where human review protects customers, and where evidence must be retained for audit and regulatory challenge.

For Malla Banking Academy, the takeaway is simple: this topic belongs to banking first and technology second. AI and ML become valuable only when they are connected to capital, provisions, payments, fraud, sanctions, liquidity, reconciliation, reporting, customer treatment and operational resilience. That is the difference between a generic AI explanation and a bank-grade learning chapter.

The accounting question behind a credit score

IFRS 9 expected credit loss (ECL) is an accounting estimate for financial assets and certain commitments within its scope. It is not a ranking of customers for a new loan, a capital requirement or a prediction that one named borrower will default. The estimate asks what cash shortfalls the reporting entity expects, using relevant past events, current conditions and reasonable, supportable forward-looking information. A bank may use statistical models to support that estimate, but accounting policy determines the measurement and presentation. The IFRS Foundation's IFRS 9 standard page is the primary starting point for the requirements. An institution must use the current applicable standard and its own accounting advice.

A business analyst should start with the reporting population. Which loans, receivables, debt securities, loan commitments or financial guarantees fall within the impairment requirements? Which entity owns them at the reporting date? Which product, currency, effective date and accounting classification apply? A model cannot answer those accounting-scope questions from transaction history alone. The bank needs an authoritative instrument record and a reconciliation to the ledger before calculating losses.

The estimate changes as risk changes. The widely used three-stage explanation is a learning aid for instruments that follow the general approach, not a claim that every IFRS 9 instrument uses identical staging. Stage 1 uses 12-month ECL when credit risk has not increased significantly since initial recognition. Stage 2 uses lifetime ECL after a significant increase in credit risk (SICR), before credit impairment. Stage 3 is credit-impaired and also uses lifetime ECL, with a different basis for interest revenue recognition. Purchased or originated credit-impaired assets have distinct requirements. A bank should not use a generic staging rule without checking the standard, product and accounting policy.

A 12-month ECL is not simply the cash that will be lost over the next twelve months. It reflects lifetime cash shortfalls resulting from default events possible within the next twelve months. A lifetime ECL considers defaults possible over the expected life. Those definitions matter when a team labels a probability of default (PD) output, develops an exposure at default (EAD) estimate or explains a stage movement.

A dated portfolio, not a single score

Imagine a fictional bank closes its accounts on 30 September. It has unsecured instalment loans, revolving credit lines and a small portfolio of corporate loans. A nightly risk score file arrives, but the finance team cannot simply multiply each current score by today's balance and book the result. It first reconciles the eligible contracts to the ledger, checks reporting-date status and identifies off-balance-sheet commitments within scope. It records the source extract time, product mapping, currency, contract dates and exclusions.

A loan originated in January with a PD estimate at initial recognition needs a comparable current risk assessment at the reporting date to evaluate SICR. The bank cannot infer a significant increase solely from a high current PD. A borrower who began with high risk might remain broadly at the same relative risk, while a borrower who began with low risk may have deteriorated materially. The bank's accounting policy may use quantitative and qualitative indicators, subject to the standard's requirements. Days past due, forbearance, watchlist status and other evidence need defined meanings and effective dates. An override requires authority, reason and a retained record.

Suppose the risk file is missing a subsidiary's loans. Publishing a portfolio ECL number for the remaining entities as though it were complete creates a finance-control failure. The process should reconcile expected and received contract counts and carrying amounts by source, legal entity and product. It should report rejected records and missing model inputs. An approved contingency may use an alternative estimate, but it needs a dated owner, documented method and impact assessment. A technical job's success flag does not prove the population is complete.

The portfolio snapshot is a reproducible accounting input. A later payment, credit-limit change or customer correction may alter the next reporting period or prompt a restatement review, but a replay of the 30 September estimate should use information available under the reporting-date policy. The team should distinguish the event date, source-posting date, model processing time and accounting effective date. Without those four clocks, a later data refresh can silently rewrite the story of a prior estimate.

From PD, LGD and EAD to an ECL estimate

PD, loss given default (LGD) and EAD can be useful building blocks, but their product is an oversimplified teaching shortcut, not the full IFRS 9 measurement rule. The estimate concerns expected cash shortfalls, their timing and discounting, and the range of possible outcomes. Banks may implement this with term structures, scenarios and cash-flow models. The definitions used for accounting can differ from those used for prudential capital or origination decisions. A risk model's PD should not be copied into an accounting engine without checking horizon, calibration population, default definition and the treatment of forward-looking conditions.

Take an illustrative performing loan with a contractual remaining life of three years. A simple Stage 1 view considers default events possible in the next twelve months and the resulting cash shortfalls over the loan's remaining life. If the loan moves to Stage 2, the estimate considers default events across the remaining expected life. Neither statement supplies a universal percentage or a guaranteed provision. The bank's own data, contracts, scenario assumptions and accounting method determine the estimate. A fixed "Stage 2 equals three times Stage 1" shortcut would be indefensible across different maturities and risk profiles.

For a revolving commitment, exposure at a future default may include drawn balances and a portion of unused availability. The bank needs to know the contractual and behavioural assumptions, the period over which exposure is estimated, cancellation rights and the link between the loan and commitment. For a secured loan, LGD may depend on collateral value, recovery timing and costs. A current collateral value is not necessarily the value at a future default. These are model assumptions to test, not facts to hide in a spreadsheet.

A scenario-weighted result can reflect different macroeconomic paths. The bank must explain the scenario design, weights, data source, forecast horizon and transition to longer-run assumptions. It should challenge whether a small number of scenarios represents material nonlinear outcomes. A favourable base case should not erase a plausible adverse path. An expert adjustment may address a known model limitation or new information, but should state its rationale, quantified effect, owner, approval and reversal criterion. A permanent unexplained overlay is a governance problem.

Significant increase in credit risk

SICR compares the change in default risk over the expected life since initial recognition, subject to the IFRS 9 framework and the bank's accounting policy. A model can support the comparison, but the stage decision also uses qualitative information. The analyst should ask what initial-recognition risk data exists for older loans, how modifications are treated and how the bank handles products for which a direct comparison is difficult. A missing origination snapshot is a data defect that needs a documented method, not an invitation to assume no change.

Consider a fictional customer whose current PD rises from a very low level while repayments remain current. Another customer already had elevated risk at origination and shows a smaller change. An absolute PD threshold could stage the second and leave the first in Stage 1 even when the first has deteriorated more relative to its starting point. A relative threshold alone can also mislead when small baselines produce large ratios. The policy should combine quantitative analysis with other relevant information and be validated on the bank's portfolio.

Arrears can be a late signal. A customer may ask for a concession, experience sector stress or show other signs of deterioration before missing a payment. Conversely, an isolated operational posting error might temporarily create an arrears flag. The bank must define evidence review, correction and override paths. A model that consumes a stale collections status may move many accounts incorrectly. The owner should compare source records with the stage-movement report, investigate concentrations and assess the financial impact of a defect.

The IASB's 2024 post-implementation review concluded that the impairment requirements were working as intended and that no further project work was required. That conclusion does not validate an individual bank's staging thresholds or data. An implementation must still demonstrate why its criteria identify significant increases in credit risk for its portfolio.

A month-end movement with an audit trail

Follow one fictional loan. It was originated in January, made scheduled payments through July and received a hardship-related modification in August. At 30 September, the bank evaluates the contract, the modification, payment record, current risk estimate and relevant qualitative indicators. It decides a stage under its approved policy and measures ECL with the appropriate horizon. The reporting package should link the contract ID, original-recognition evidence, current data, stage result, model version, macro scenario set, adjustment and journal entry.

The analyst should test both the movement and the reason. A stage-movement report shows opening Stage 1, 2 and 3 balances, new originations, repayments, derecognitions, transfers and closing balances. The totals must reconcile to the underlying instrument population and accounting records. A loan can move stage without a new draw; an increase in ECL can come from stage, exposure, macro assumptions, model recalibration or management adjustment. A single "provision increased" number does not explain which factor changed.

The process needs an exception route when a source feed arrives late or an instrument has no usable risk estimate. Finance, credit risk, data and technology teams should agree the cut-off, materiality assessment, contingency method and sign-off authority. If a corrected feed arrives after a journal entry, the bank should document whether it reruns, adjusts, defers or escalates according to its close policy. The original result and correction should both remain traceable. A dashboard that silently replaces the original number prevents a reviewer from understanding the actual reporting sequence.

Controls also apply to manual adjustments. An analyst may propose an overlay because a current event is not captured by historic model data. The proposal should identify affected population, calculation, evidence, alternatives and uncertainty. A separate approver checks it. When the underlying condition changes or the model is updated, the bank revisits the overlay. A sequence of overlays cannot substitute for repairing a known data defect indefinitely.

Where ML can help and where it cannot settle accounting

Machine learning can support PD estimation, segmentation, early-warning analysis and some data-quality detection. It may identify interactions that a simple scorecard misses. It can also overfit a historical credit cycle, encode policy selection effects or behave differently when customer mix changes. A high discrimination score does not demonstrate that lifetime ECL is correctly measured. The bank must test calibration, scenario sensitivity, stability, explainability and the effect on reported amounts.

Training data should be point-in-time correct. A collections note written after a borrower defaulted cannot be a predictor for the prior month-end. A loan that was sold or closed must be treated according to the population and outcome definitions rather than disappearing from a historical cohort. Development, validation and accounting owners should review label maturity, missing data, restructurings, defaults and recoveries. A model trained on only one product or geography should not be applied to another without evidence.

The model output travels through accounting controls. An approved model may provide a PD curve, but the ECL engine also needs contractual cash flows, exposure assumptions, recovery estimates, scenario weights and discounting. Finance decides the accounting policy and signs off the result. A generative AI assistant may help locate policy text or draft a variance narrative with citations, but it should not invent a stage reason or post a journal entry. A human reviewer verifies the source and arithmetic before any financial-statement impact.

The Federal Reserve's 2026 model-risk guidance is a U.S. supervisory source for covered organisations and model uses. It should not be presented as an IFRS 9 accounting requirement or applied globally. IFRS 9 is the accounting source; local adoption and supervisory expectations also require jurisdiction-specific review. Keeping these authorities separate prevents a learning chapter from treating prudential validation and accounting measurement as the same rule.

Acceptance cases for a banking team

A useful test pack begins with a performing new loan, an older loan with a material risk change, a credit-impaired loan and an instrument that follows a distinct impairment approach. It includes a revolving commitment, a modified loan and a loan whose source data arrives late. For each case, check eligibility, stage or measurement approach, ECL horizon, input versions, calculation path, approval and journal mapping. The expected outcome should be derived from approved policy and the applicable standard, not from an unexplained model default.

Test a boundary case near a SICR threshold and a qualitative indicator that overrides the numerical result. Verify who can approve the override and how it appears in the stage-movement report. Test an account whose arrears status is corrected after the reporting cut-off. The replay should show what the bank knew when it closed the books and what changed later. A missing data feed should create an explicit exception, not a fabricated zero loss.

A validator can compare predicted defaults and losses with matured outcomes, but a single short period cannot establish lifetime accuracy. Break the analysis down by origination vintage, product, stage and relevant risk segment. Review whether macro scenarios behave sensibly when conditions deteriorate. Inspect the effect of a model update separately from a portfolio change. Audit should be able to select one reported balance and trace it back to instruments, inputs, transformations, models, adjustments and approvals.

The final hand-off is a controlled accounting estimate with uncertainty. The learner should be able to state which instruments were measured, which information was available at the reporting date, why the horizon was chosen, which assumptions drove the number and what evidence supports the journal. That is the practical connection between AI modelling and IFRS 9 reporting.

A scenario calculation to challenge, not copy

Use a deliberately simplified classroom example. A fictional bank has a loan with 100 units outstanding and two possible macroeconomic paths. Under one path, expected cash shortfalls are modest; under the other, a sector downturn increases defaults and delays recoveries. If the bank assigns weights to those paths, it calculates a weighted estimate after applying the appropriate measurement horizon and discounting. The class can practice the arithmetic with assumed numbers, but the result must be labelled an illustration. Real IFRS 9 measurement is based on the instrument's cash-flow rights and the reporting entity's reasonable, supportable information, not on a universal PD times LGD percentage.

The first challenge is the population. If the bank accidentally excludes loans in forbearance from the scenario run, the weighted answer can look internally consistent while omitting the most relevant accounts. The second is timing. A scenario published after the close may be useful for a subsequent review, but the bank must decide, under its reporting policy, what information was available and relevant at the reporting date. The third is horizon. A Stage 1 estimate and a Stage 2 estimate can use the same economic information yet differ because the default-event horizon differs. Simply scaling the Stage 1 result by the contractual number of years would ignore changing risk, exposure, repayments and discounting.

A fourth challenge is dependence. In a downturn, default probability may rise while collateral recovery falls and drawn exposure increases. Assuming independent, fixed inputs can understate the interaction. Conversely, a model that double-counts the same macro stress in PD and a management overlay can overstate loss. The bank needs sensitivity analysis showing which assumptions move the estimate. That analysis should be understandable to finance and risk owners, not only the developer who built the code.

Suppose the bank revises its forecast at the next quarter-end. The analyst should preserve both dated scenario sets and compare effects on ECL using a controlled bridge. Some movement comes from new lending and repayments, some from stage transfers, some from changed macro assumptions and some from actual defaults or recoveries. The bridge lets reviewers identify why the allowance changed. It also helps testers construct cases where an input changes but the output should stay constant, and cases where a stage move should have a visible effect.

A model can make this process scalable, but it cannot define the accounting policy, approve the forecast or decide whether a management adjustment is justified. Those decisions require named roles and a sign-off record. The classroom example is complete when a student can trace one number from a dated contract through the scenario inputs and cash-shortfall estimate to the allowance and journal, then explain every difference between two reporting dates.

Handoff between risk and finance

The risk team owns model development and performance evidence; finance owns the accounting conclusion and ledger control. Data teams maintain source definitions, while operations resolves exceptions that affect instrument status. These are functional roles in the fictional example, not a universal organisation chart. The hand-off should state the reporting population, run identifier, approved model and scenario versions, rejected-record count, adjustments, sign-offs and reconciliation totals. A finance reviewer should not need to infer an input from an undocumented spreadsheet cell.

A change request should describe whether it affects data, stage rules, estimation method, overlays or presentation. The regression set should rerun representative contracts and explain expected differences. If a release fails after close, the bank needs an approved recovery and correction route. These controls let a reader distinguish a model improvement from an unapproved accounting change.

Source notes for further study

IFRS Foundation, IFRS 9 Financial Instruments; BIS FSI summary on IFRS 9 expected loss provisioning.

Additional banking practice note 1

A real bank should never treat this chapter as only a model-building exercise. The model sits inside policy, architecture, workflow, risk appetite, customer communication, operational support and evidence retention. That full chain is what makes the solution bank-grade rather than experimental. In the context of ifrs 9 and expected credit loss modelling, this means the team should document the exact portfolio, channel, product, process and control boundary before making design decisions. A retail credit example, a corporate treasury example, a sanctions alert example and an instant payment example may all use data-driven scoring, but the risk owner, evidence requirement and customer impact are different.

A useful working question is: if this output is challenged later, who can explain why the bank trusted it? The answer should include the business owner, data owner, model owner, validation evidence, monitoring result, user action and stored audit trail. If that answer is weak, the bank may have analytics, but it does not yet have a controlled banking capability.

Additional banking practice note 2

The practical difficulty is usually not the algorithm. It is agreeing the definition, finding the trusted source, proving the data timing, making the output usable for staff, preventing misuse, monitoring outcomes and explaining the result months later to someone who was not part of the delivery team. In the context of ifrs 9 and expected credit loss modelling, this means the team should document the exact portfolio, channel, product, process and control boundary before making design decisions. A retail credit example, a corporate treasury example, a sanctions alert example and an instant payment example may all use data-driven scoring, but the risk owner, evidence requirement and customer impact are different.

Additional banking practice note 3

This is also why business analysts matter so much in banking AI work. They translate between risk language, product language, operations language, data language and technology language. Without that translation, a technically good model can still fail because the bank cannot use it safely. In the context of ifrs 9 and expected credit loss modelling, this means the team should document the exact portfolio, channel, product, process and control boundary before making design decisions. A retail credit example, a corporate treasury example, a sanctions alert example and an instant payment example may all use data-driven scoring, but the risk owner, evidence requirement and customer impact are different.

Additional banking practice note 4

The strongest implementation pattern is staged adoption. First understand the current process. Then run the model silently. Then compare with existing decisions. Then expose it as decision support. Then automate only low-risk paths when monitoring evidence proves that the use case is controlled. In the context of ifrs 9 and expected credit loss modelling, this means the team should document the exact portfolio, channel, product, process and control boundary before making design decisions. A retail credit example, a corporate treasury example, a sanctions alert example and an instant payment example may all use data-driven scoring, but the risk owner, evidence requirement and customer impact are different.

Additional banking practice note 5

Customer impact must remain visible. A false positive can delay a genuine payment, decline a good customer, create a complaint or overload operations. A false negative can allow fraud, credit loss, financial crime exposure or regulatory breach. Both sides of error need business cost and control ownership. In the context of ifrs 9 and expected credit loss modelling, this means the team should document the exact portfolio, channel, product, process and control boundary before making design decisions. A retail credit example, a corporate treasury example, a sanctions alert example and an instant payment example may all use data-driven scoring, but the risk owner, evidence requirement and customer impact are different.

Additional banking practice note 6

The chapter should therefore be read as part of the larger AI and ML banking journey. Data foundation, feature design, model governance, production monitoring, fallback, human oversight and audit evidence are not separate topics. They are the operating model that allows AI to be adopted safely. In the context of ifrs 9 and expected credit loss modelling, this means the team should document the exact portfolio, channel, product, process and control boundary before making design decisions. A retail credit example, a corporate treasury example, a sanctions alert example and an instant payment example may all use data-driven scoring, but the risk owner, evidence requirement and customer impact are different.