In short. Bank ECL files fail audit in four recurring ways: staging triggers that are written but not enforced, scenario weights that are governed in committee but not documented in the model, post-model adjustments that grow without challenge, and disclosure narratives that are inconsistent with the underlying model inputs. None of the four is hard to fix. All four are common to find. The fix is governance discipline rather than model rebuilding.

1. The territory

IFRS 9 has been in force for retail and corporate banking entities since 2018. The model architecture is stable; the governance overlay around it is not. After multiple cycles of FRC thematic review, PRA supervisory feedback, and audit firm methodology refresh, the recurring failure modes in ECL files are well documented. They are also remarkably consistent across institutions, which is the giveaway that the problems are structural rather than firm-specific.

What follows is the set of failures I have seen most often in UK banking ECL audits, and what works to address each. The tone here is deliberately practical. The model-theoretic literature on ECL is substantial; the practical workpaper-and-governance literature is thin. This is a working note about the workpaper.

2. Staging triggers: the written-versus-enforced gap

Every IFRS 9 model has a stated set of staging triggers. The policy says: an exposure moves from Stage 1 to Stage 2 on a defined deterioration signal — commonly a multiple of probability-of-default at origination, or a series of payment-status indicators, or a combination. The policy is written, approved by the risk committee, and circulated through the audit pack.

The recurring failure is that the policy and the model code do not agree. The policy may say “PD doubles from origination”; the code may apply “PD increases by a factor of 1.8” because that was the calibration the model team landed on six months earlier when the model was last retuned. Both are defensible numbers; only one is in the policy. The file presents the policy and the model output without ever placing the two next to each other to confirm consistency.

The fix is a reconciliation workpaper that does exactly that: states each policy trigger, states the corresponding implementation in code, and confirms that the two match. Where they do not match, the file documents which is the operative version and what governance approved the variance. This workpaper is rarely more than three pages. Its absence is a recurring inspection point.

3. The forward-looking information overlay

IFRS 9 paragraph 5.5.17 requires the inclusion of reasonable and supportable forward-looking information when measuring ECL. In practice this is implemented through a small number of macroeconomic scenarios — a base case, a downside, an upside — weighted to produce a probability-weighted ECL.

Three subordinate failures cluster here.

Scenario weighting. The weights are governance decisions. They emerge from a committee meeting that considers macroeconomic outlook, regulatory commentary, and house view. They are also frequently undocumented as decisions. The risk committee minute records that weights were discussed and approved; it does not record the analytical basis. A reviewer asks “why fifty-thirty-twenty rather than forty-forty-twenty” and the file is silent. The fix is a one-page scenario-weighting memorandum, drafted by the model owner, recording the analytical basis, the alternatives considered, and the conclusion. Signed and dated. Stored in the model governance file rather than buried in committee minutes.

Scenario severity calibration. The downside scenario is supposed to be severe but plausible. Severity is a judgment. In observed cases the downside scenario has not moved meaningfully across three or four reporting cycles, despite materially different macroeconomic conditions in each. This is not necessarily wrong, but the absence of an explicit recalibration discussion is. The fix is to require each reporting cycle to produce an explicit recalibration note — whether the conclusion is “recalibrated upward”, “recalibrated downward”, or “held; rationale below”.

Scenario internal consistency. Macroeconomic scenarios specify multiple variables: GDP, unemployment, house-price index, base rate. The variables are supposed to move together in plausible combinations. A reviewer should be able to read the downside scenario and find a coherent macro story. Often the variables have been calibrated individually, against individual time series, and not assembled into a coherent narrative. The fix is a one-page scenario-narrative memorandum that tells the story of each scenario in prose, and confirms that the variable combinations are consistent with that story.

4. Post-model adjustments: the quietest weakness

This is, in my experience, the single most consistent file weakness in ECL audits across the UK banking sector.

Every ECL model produces an output. Almost every bank then applies a set of adjustments to that output. The adjustments may be small and prudent, large and material, or somewhere in between. They are commonly called post-model adjustments, management overlays, or in-life adjustments. They are typically introduced for sound reasons — the model cannot yet reflect a known sector deterioration, the model is being recalibrated and the existing version under-reads a recent stress, a specific portfolio is too small to model and is overlaid as a top-up.

Three recurring problems with PMAs.

They do not get retired. A PMA introduced in response to a specific 2021 sector stress was still on the books in 2024, after the stress had passed. The reason no one removed it: no one was explicitly accountable for retirement, and removing a PMA reduces ECL, which felt imprudent. The result is a stack of overlays whose individual rationales no longer hold and whose aggregate effect is significant.

They are governed weakly. The governance framework for introducing a PMA is often less robust than the governance framework for the underlying model. A model change requires risk committee approval, validation, and documented evidence; a PMA is sometimes introduced through a memorandum and a senior-officer sign-off, with materially less rigour.

They blur the line between model risk and management judgment. The model output is, at least nominally, a model-risk quantity governed by model risk management (SS1/23). The PMA is, at least nominally, a financial-reporting judgment governed by the controller. In practice the PMAs are often constructed by the model team, applied by the controller, and audited as if they were model outputs. The accountability map becomes unclear.

The fix is a PMA register. One sheet per PMA. Date of introduction, originating rationale, methodology used to size, expected retirement date or retirement criteria, current period justification, ownership, and approval trail. The register is reviewed each reporting cycle by both model risk and controller; PMAs that do not survive the review are retired or restated. The register is the workpaper that an auditor or a reviewer reads first.

5. Disclosure consistency: the line that loses inspections

IFRS 7 paragraph 35 sets the disclosure requirements for credit risk. In practice the disclosure narrative is drafted by the financial reporting team and the model inputs are owned by the risk team, and there is more daylight between them than there should be.

The recurring failure mode is straightforward: the narrative describes the scenario weighting one way and the model uses different weights; the narrative describes the staging triggers one way and the policy says something else; the narrative claims a specific severity calibration for the downside scenario and the actual variables in the model do not match that severity. None of these are intentional misstatements. They are the result of two teams drafting two documents from two starting points and never explicitly cross-referencing them.

This is exactly the kind of finding that FRC inspections flag. The narrative is wrong because the model team did not see it before publication; the model is right but the disclosed description does not reflect it. The auditor’s file shows the model and shows the narrative but does not show the consistency check.

The fix is a single workpaper, owned by audit and produced each reporting cycle, that takes every numerical and methodological assertion in the credit risk disclosure and ties it back to an underlying model input or policy document. It is laborious the first time; it takes thirty minutes the second time once the template exists. It is the single most defensive workpaper in an ECL audit file.

6. The audit response: ISA 540 in this specific context

ISA (UK) 540 (revised December 2018, in force for periods beginning on or after 15 December 2019) sets the structure for auditing accounting estimates with significant uncertainty, of which ECL is the canonical example. The audit response to ECL needs to include, at minimum, the following workpapers:

  • Inherent risk assessment at the assertion level, identifying the components of ECL with the highest estimation uncertainty (typically: scenario weights, post-model adjustments, staging in concentrated portfolios).
  • Methodology evaluation documenting the auditor’s view of the appropriateness of the model framework, scenario design, and governance.
  • Source-data testing covering the inputs to the model: loss given default rates, exposure at default, probability of default, and macroeconomic scenario variables.
  • Model implementation testing, typically performed by an audit firm’s in-house modeller, comparing the documented methodology to the implemented code on a sample basis.
  • Management bias evaluation, which is the part of the file most commonly underdone. This requires the auditor to consider whether the cumulative direction of judgments — staging, weighting, PMAs — trends in any single direction, and whether that direction is consistent with management incentives.
  • Sensitivity and stress workpaper, recording the auditor’s independent sensitivity analysis around key parameters and documenting the materiality of the parameters tested.
  • Disclosure consistency workpaper, as described above.
  • Concluding memorandum on the overall reasonableness of the ECL estimate, signed by the engagement partner.

Eight workpapers. Each can be done in a half-day to a day, with the right templates. The total ECL audit footprint in a well-organised file is roughly fifty to seventy pages. In a poorly organised file it is two hundred and fifty pages and reaches the same conclusion with less defensible evidence.

7. Where AuditEngine fits in this

Of the eight workpapers above, four are largely deterministic and four require senior judgment. The deterministic four — methodology evaluation, source-data testing, model implementation testing structure, and disclosure consistency — are the natural targets for tooling. AuditEngine drafts these workpapers from operator-supplied inputs and the auditor’s methodology decisions, in the same opinionated format each time, with citation discipline preserved.

The other four — inherent risk assessment at engagement level, management bias evaluation, sensitivity workpaper interpretation, and the concluding memorandum — remain entirely the work of a human senior auditor. Bias evaluation in particular is a place where tooling has no business pretending to substitute. The right architectural response is to do the deterministic work in roughly half the time it would otherwise take and use the saved capacity on the judgment workpapers.

8. The governance layer the file ultimately depends on

Every individual workpaper described above depends on a single underlying governance discipline at the bank: somebody owns the ECL model and somebody owns the ECL estimate, and these are not the same person. The model owner is normally in risk; the estimate owner is normally in finance. The boundary between them is the place where most of the failures cluster, because work that falls into the boundary tends not to get done by either side.

The single most useful governance recommendation an auditor can make at the end of an ECL audit is to require, in writing, a one-page ECL accountability map: who owns each component, who reviews it, who challenges it, and where the boundary is. Banks that have this document tend not to repeat the failures listed above. Banks that do not have it tend to repeat them every cycle. The document is not in IFRS 9 and not in IFRS 7. It is in good order.

9. Closing observation

The interesting question about IFRS 9 ECL audits is not the modelling. The modelling is largely solved; banks have invested enormously in their ECL models since 2018 and the technical sophistication is high. The interesting question is the governance overlay, which is where most of the file weakness still lives. A senior auditor reading an ECL file should be able to trace, in a few minutes, the path from policy to code to model output to PMA to disclosure narrative. When that path is traceable, the file holds. When it is not, the file fails inspection, the bank gets a finding, and the audit team spends six weeks reproducing what should have taken two days the first time.

The fix in every case is documentation discipline applied at the boundary between teams. Unspectacular. Effective. The work of a senior auditor who has done this before and knows where the gaps reliably sit.

— DK Buledi, February 2026