End user computing in banking: why three regulators now watch the same estate

A quarterly credit risk calculation, a provisioning model last documented by someone who left two years ago, a capital committee pack assembled from five spreadsheets that three teams maintain independently. Every credit risk function has a version of this story: the tool that started as a one-off answer to a time-pressured question was passed along and extended, and is now embedded in a business process far beyond anything its first author intended.

End user computing (EUC) is the collective term for applications owned and operated outside a bank’s formal IT governance processes. Spreadsheets account for the largest share, but the category also covers Access databases, desktop analytical models, and any tool built and maintained by business users without central IT change control.

The category matters because supervisory treatment of EUC has hardened considerably. Three frameworks now press on the same estate, each from a different direction. The Basel Committee on Banking Supervision (BCBS) treats EUC failures as operational risk in its standard BCBS d515. The Prudential Regulation Authority (PRA) has a model risk statement, SS1/23, that pulls any spreadsheet that applies statistical or financial theory into full model governance, and our SS1/23 guide covers what that governance requires.¹ The risk-data-aggregation principles, BCBS 239, require the spreadsheets feeding risk reports to be controlled and traceable, and our piece on BCBS 239 covers how far banks still are from meeting them.² Each creates distinct governance obligations that compound rather than substitute for one another.

Why do banks end up with unmanaged EUCs?

Banks do not typically decide to build EUCs. They accumulate them. A spreadsheet built to answer a one-off question becomes the template for the next quarter’s run. A model recalibration written under time pressure gets reused six months later without review. A calculation that no one has time to formalise becomes, over several reporting cycles, the calculation the firm relies on.

Four pressures have driven UK banks to address this accumulation of EUCs more formally:

• Reputational risk from errors reaching external reporting, such as a published capital figure later traced to a broken spreadsheet formula.
• Regulatory compliance demands. The UK’s Sarbanes-Oxley-style statutory route closed when the Audit Reform and Corporate Governance Bill was abandoned in January 2026, but Provision 29 of the UK Corporate Governance Code took its place and applies to financial years beginning on or after 1 January 2026. Boards must now declare whether their material controls were effective at the balance sheet date, which is difficult to do over an estate nobody has catalogued.³
• Audit committee scrutiny of data and processing integrity.
• Operational efficiency costs from EUC duplication and inconsistency, such as three teams maintaining separate versions of the same capital calculation.

Not all spreadsheets carry the same risk

Governance frameworks that treat all EUCs as a single risk category tend to impose overhead on the wrong tools while missing the ones that matter. Sorting the estate before governing it is the point of a nine-type taxonomy structured across two axes: the tool’s use case, and the engineering resources applied to its construction. The distinction decides which tools need the full model-risk regime and which do not.

The highest-risk category in the nine-type taxonomy is the "field expedient" model: a tool built for personal productivity that has drifted into a business-critical role without the engineering investment the role requires. The provisioning model still run by the team that inherited it, and the capital committee pack assembled from five spreadsheets, are both exactly this. Version control, formula documentation, peer review, and change management are absent, not through intent but because no one recognised that the tool had changed its function.

The failure modes that concentrate in this category have been catalogued by the European Spreadsheet Risks Interest Group across more than two decades of conference proceedings, and every credit risk analyst will recognise them:⁴

1. Hard-coded constants. Embedded in formulae rather than in labelled reference cells, making the constant invisible to any later reviewer.
2. Silent cell reference breaks. Cell references that break when rows or columns are inserted or deleted, producing incorrect outputs with no error indicator.
3. Copy-paste duplication. Creates parallel versions of a calculation which diverge over time as one copy is updated and the other is not.
4. Single-author knowledge. Resides only in the builder’s memory and disappears when the builder leaves.

These four spreadsheet failure modes are the empirical basis on which supervisors have built their expectations.

Which regulations govern EUC, and how do they interact?

No single regime fits every tool, so the supervisory pressure on EUC is not concentrated in one regulation but assembled from three.

The operational risk anchor is BCBS d515, the Basel Committee’s 2021 revision to its operational risk principles. Basel defines operational risk as “the risk of loss resulting from inadequate or failed internal processes, people and systems or from external events”, including legal risk but excluding strategic and reputational risk.⁵ Spreadsheet errors sit squarely inside that definition. They arise from exactly the missing version control and change management the principles address, and the familiar three lines of defence apply: first-line business ownership, second-line oversight, third-line internal audit.

The model risk layer operates through SS1/23, the PRA’s supervisory statement on model risk management (effective May 2024). It requires UK-authorised banks to identify every model in use and classify its risk. SS1/23’s test is what the tool does, not how it was built.

SS1/23 defines a model as “a quantitative method, system, or approach that applies statistical, economic, financial, or mathematical theories, techniques, and assumptions to process input data into output”.⁶ A spreadsheet that applies theory in that way is a model and enters the full model risk management (MRM) regime, however crudely it is assembled. A purely deterministic tool, a rules-based calculation however elaborate, falls outside the definition. A tool outside the model definition does not escape governance: where such methods are complex and bear materially on business decisions, firms should consider applying relevant parts of the MRM framework, and the PRA expects documented management controls over them regardless.

A spreadsheet that meets the SS1/23 model definition must be tiered against the firm’s model risk appetite, independently validated, and subject to ongoing performance monitoring.

The data governance layer runs through the Basel principles on risk data aggregation and reporting (BCBS 239): banks must control and evidence the data behind their risk reports. The European Central Bank (ECB) carries this through to capital in its May 2024 guide on risk data aggregation and reporting (RDARR): data quality issues “might lead to an underestimation of risks and should be addressed in the risk quantification by an additional margin of conservatism” in the Internal Capital Adequacy Assessment Process (ICAAP) and the Internal Liquidity Adequacy Assessment Process (ILAAP).⁷ A spreadsheet that feeds a risk figure is one of those data sources.

The principle is long-standing, but supervisory attention has sharpened. The ECB’s May 2024 RDARR guide requires the significant institutions it supervises to integrate end-user computing into data quality management, keeping an overview of such applications and documenting manual workarounds with an audit trail “until the data preparation and reporting steps that are determined to have a material impact on data quality are embedded in an audit-trailed IT-controlled environment”.

Which EUCs count as models, and what that triggers

Of the three frameworks, the model-risk layer draws the sharpest line. SS1/23 forces a binary decision for every EUC: does it apply statistical, economic, financial or mathematical theory to turn inputs into outputs? The answer determines the governance burden.

Qualifying EUCs enter the model inventory with full MRM obligations: tiering, independent validation, and ongoing monitoring. An EUC that does not meet the definition sits within operational risk and data governance scope, and, if it is complex and material to business decisions, still attracts documented management controls and a decision on which parts of the MRM framework to extend to it.⁶ The compliance cost difference between the two outcomes is substantial, which gives every firm an incentive to draw the boundary narrowly. In Gini’s experience that is exactly where supervisory attention goes, and SS1/23’s insistence that the scoping methodology be demonstrable reads as an answer to it.

The model boundary decision must be documented, and the scoping methodology must be demonstrable. Firms that cannot explain how they drew the model boundary are not in a meaningfully different position from those that drew it too narrowly. Without a well-executed EUC inventory, the model boundary question cannot be answered systematically.

What should an EUC inventory record, and who owns it?

Governance of the EUC estate has become a documented requirement rather than an aspiration. The starting point is a single inventory that records every tool, its use case, its engineering grade, and a named owner for each entry. Running EUC discovery and model inventory as one programme, rather than two, is what keeps that inventory honest. The capital committee pack built from five untracked spreadsheets is exactly the kind of tool the inventory has to capture, because every subsequent obligation, from tiering to validation to the audit trail, depends on it being recorded there. Each quarter that pack runs unrecorded, the gap between the real estate and the documented one widens.

Frequently asked questions