End user computing controls and the workbook in your risk report

End user computing controls, or EUC controls, are the controls a bank applies to spreadsheets, desktop databases, scripts and other tools that business users build and run themselves, outside IT's change management: an inventory, a risk rating, version and change control, access control, review and sign-off, reconciliation of what goes in and comes out, and testing. BCBS 239 names them directly. Where a bank relies on "manual processes and desktop applications (eg spreadsheets, databases)", Principle 3 says "it should have effective mitigants in place (eg end-user computing policies and procedures) and other effective controls that are consistently applied across the bank’s processes" (BCBS 239, paragraph 36(b)). The hard part is that the riskiest workbooks sit in the middle of reporting chains, where catalogs do not see them and end-of-chain checks do not test them. Botminds' BCBS 239 Compliance finds the workbooks in the lineage of each critical figure, rates them, and puts the owner's attestation and the fix on the record.

The workbook examined here belongs to a fictional sample bank, Corvane National Bank: the spreadsheet at hop 4 of its board's commercial real estate exposure figure.

What are end user computing controls?

They are the subset of general IT controls that a bank has to apply where IT does not run the application. A system in production has change management, access control and testing because IT provides them; a workbook on a file share has whatever its author gave it. EUC controls close that gap in proportion to risk. The ECB's 2018 review described what good looked like at the banks it examined: "Manual interventions – including supporting end-user computing (EUC) tools – were traced and ranked by complexity and relevance", modifications were "subject to independent validation and/or approval", and "EUC tools designed to support the application of access controls, the segregation of duties, and the separation of testing and production" (ECB Thematic Review, 2018).

In practice the controls fall into three groups. Knowing: an inventory of the tools that matter, with an owner and a risk rating for each. Constraining: version control, change control, access control and protection of formulas and inputs. Checking: reconciliation of inputs to their sources and outputs to their destination, independent review before use, and periodic testing. The tier a tool falls in decides how much of each it needs.

Does BCBS 239 cover spreadsheets?

Yes, explicitly, and the ECB goes further. Beyond paragraph 36(b), BCBS 239 expects banks "to document and explain all of their risk data aggregation processes whether automated or manual", with "an explanation of the appropriateness of any manual workarounds, a description of their criticality to the accuracy of risk data aggregation and proposed actions to reduce the impact" (paragraph 39). It defines manual workarounds as "Employing human-based processes and tools to transfer, manipulate or alter data used to be aggregated or reported" (Annex 1). A workbook that pulls a warehouse extract, adds participations and overrides, and uploads a total is exactly that.

The ECB's Guide makes end-user computing part of data quality management rather than a side policy. It expects "The full integration of end-user computing or end-user developed applications, including an overview of such applications, into data quality management policies and processes" (ECB Guide on RDARR, May 2024, section 3.5). It also expects manual workarounds in scope to be documented and controlled, with four-eyes review, an audit trail of changes, overrides and sign-offs, until the steps that materially affect data quality run in an audit-trailed, IT-controlled environment. That last condition is the end state: control the workbook while it exists, and retire it into a governed process where it matters.

What is end user computing risk?

It is the risk that a user-built tool produces a wrong number that someone relies on, and that nobody notices. Research on spreadsheets is unusually consistent. Ray Panko's review for the European Spreadsheet Risks Interest Group concluded that "spreadsheet errors are rare on a per-cell basis, but in large programs, at least one incorrect bottom-line value is very likely to be present", that "errors are extremely difficult to detect and correct", and that "spreadsheet developers and corporations are highly overconfident in the accuracy of their spreadsheets" (Panko, EuSpRIG 2015). An earlier paper found that "only one technique, cell-by-cell code inspection, has been demonstrated to be effective" (Panko, EuSpRIG 2000).

In finance the stakes are concentrated. A study drawing on senior practitioners in the City of London suggested that it "is presently exposed to significant reputational risk through the continued uncontrolled use of critical spreadsheets in the financial markets and elsewhere" (Croll, EuSpRIG 2005). In a BCBS 239 lineage the risk has three faces at once: accuracy (the workbook changes the figure), timeliness (the workbook is where the hours go in a drill) and adaptability (a new cut needs the one analyst who understands it). The sample workbook shows all three.

A spreadsheet is usually not a model, so model risk controls will not cover it

Many banks lean on model risk management to govern important spreadsheets. The U.S. agencies' revised guidance of April 2026 narrows that route: its definition of a model leaves out the simple arithmetic of a spreadsheet and fixed rule-based processes (Federal Reserve SR 26-2, April 2026; the exclusion is quoted in customer risk rating model). The workbook behind the sample bank's commercial real estate figure does arithmetic: it adds participations and adjustments to an extract. It is not a model under that definition, so model validation will not look at it.

That leaves EUC controls as the control family that must catch it. A bank that scopes its EUC policy to models built in spreadsheets has, after April 2026, left its most common risk-data spreadsheets uncovered by either regime. The safer definition is functional: any user-built tool that transforms, adds to or overrides data on the way to a critical figure is in scope, whatever it computes.

What is an EUC inventory, and what should it record?

An EUC inventory is the register of user-built tools that matter, with enough about each to rate its risk and assign its controls. The ECB asks for "an overview of such applications"; the question is which ones, and what to record. Starting from lineage answers the first: every workbook that sits in the path of a critical data element is in, because its output reaches a board, regulatory or supervisory figure. A firm-wide scan finds thousands of spreadsheets; a lineage finds the dozens that matter, which is why the sample bank's inventory of workbooks in lineage holds 27.

How do you control spreadsheets in banking? What auditors expect to see

Control them by tier, and prove the controls ran. A low-risk tracker needs an owner and a backup; a workbook that changes a board figure needs the full set. The research favours inspection and testing over policy: Panko's 2015 paper argues "our biggest need, based on empirical data, is to do massively more testing than we do now". Internal auditors will look for evidence of each control operating, not for the policy that requires it.

What is an EUC policy, and what makes one work?

An EUC policy defines which user-built tools are in scope, how they are inventoried and rated, which controls each tier must have, who attests and how often, and when a tool must be retired. BCBS 239 asks that mitigants be "consistently applied across the bank’s processes", so a policy that each business interprets differently fails the test even if every page of it is sound. The ECB's requirement to integrate end-user computing into data quality management means the policy should share the bank's data quality indicators, issue register and escalation, not run a parallel process.

The commonest failure is a policy that exists while the workbooks it should govern are unknown. The sample bank's own history makes the point: before the trace, the workbook's owner heard that his spreadsheet was a risk without being told which cells, and the catalog listed the workbook only as a manual upload.

The workbook at hop four, found, rated and fixed in BCBS 239 Compliance

The workbook was found because the catalog's "manual upload" did not explain the mart's input. The Lineage agent joined the file-share read of the staging export, the write of the workbook and the mart job's read of the same file. The Accuracy agent then reconciled it: $212.0 million more than the staging table, $187.4 million of it 48 participations sold to other banks with the "Sold %" column blank, $24.6 million six overrides nobody has explained. The Spreadsheet agent rated it High: material, complex, uncontrolled, frequently edited.

People did the rest. The steward confirmed the hop and accepted the finding. The Assessor proposed two remediation items for the data owner: an interim reconciliation of the workbook total to the loan system before each upload, signed by a second analyst, due November 13, 2026; and retiring the workbook into a governed transformation reconciled at every load, due March 31, 2027. The owner can request their closure but never approve it. The agents never edited or locked the file: it is read only to them, and borrower names stay masked outside the steward's domain.

End user computing controls, rated with their reasons in BCBS 239 Compliance

Spreadsheet remediation with owners, dates and escalation

Where BCBS 239 Compliance fits for end user computing, and where it does not

It finds and rates the user-built tools that sit in the lineage of critical data elements, which is where BCBS 239 and the ECB focus, and it ties each one to the amounts and hours it affects. It is not a firm-wide spreadsheet scanner: a workbook that feeds no critical figure will not appear. It does not lock, edit or move files, so it cannot enforce version control or access rights; those stay with the bank's file platforms and the owner. And a rating is a proposal: the owner attests the controls, and the steward and Head of Risk Reporting decide what the finding means for each principle. Data lineage tools compared covers how the workbook was found, critical data elements in banking how its effect was measured, and the timeliness principle how its 60 hours were timed.

Questions people ask

What are end user computing controls?

Controls over spreadsheets, desktop databases and other tools built and run by business users: an inventory with owners, a risk rating, version, change and access control, reconciliation of inputs and outputs, review of overrides, independent review and testing, applied in proportion to each tool's risk.

What is an EUC inventory?

A register of the user-built tools that matter, recording for each its owner, location, what it feeds, its complexity, its controls, its risk rating and its retirement plan. The ECB expects an overview of end-user computing within data quality management; building the inventory from lineage ensures it covers the tools that reach reported figures.

Does BCBS 239 cover spreadsheets?

Yes. Principle 3 says that where a bank relies on manual processes and desktop applications such as spreadsheets and databases, it needs effective mitigants such as end-user computing policies and procedures. Paragraph 39 requires manual workarounds to be documented with their criticality and plans to reduce their impact.

What spreadsheet controls do auditors expect?

Evidence that controls operated: the workbook in an inventory with an owner and a rating, input and output reconciliations, approved overrides with reasons, version and change history, restricted access and documented review. For material workbooks they will also ask how and when the logic moves into a governed system.

What is an EUC policy?

The bank's rulebook for user-built tools: what counts as one, how they are inventoried and rated, the minimum controls for each risk tier, who attests and how often, and when a tool must be retired. Under the ECB's Guide it should be part of data quality management, not a separate process.

Are spreadsheets models under SR 26-2?

Generally not. The April 2026 guidance excludes simple arithmetic calculations such as those in spreadsheets, and deterministic rule-based processes, from its definition of a model. A spreadsheet that applies statistical, economic or financial theory to produce estimates could still be one; most risk-reporting workbooks that add, map and override are not.