In banking, EUC stands for end-user computing: the spreadsheets, scripts, databases, and other calculation or reporting tools that business staff build and maintain outside the bank’s formal IT development process. Traders, risk analysts, and compliance officers create them because they solve problems faster than centralized IT can deliver. Regulators, including the Federal Reserve, the OCC, and the Basel Committee, treat them as a significant source of operational and compliance risk, and failures in EUC management have contributed to some of the industry’s most expensive mistakes.
What Counts as an EUC
An EUC is any digital tool used for calculations, reporting, or decision-making that was not built and maintained through the bank’s formal software development process. The most common example is the complex Excel spreadsheet with proprietary formulas for pricing derivatives, calculating capital reserves, or reconciling general ledger entries. These spreadsheets often pull data from external systems and are maintained by one person or a small team with no formal documentation.
Custom Microsoft Access databases tracking regulatory submissions also qualify, as do Python or R scripts written by quantitative analysts for market simulations. The defining characteristic is that the business user controls the design, logic, and changes rather than a dedicated IT engineering team. That distinction matters because enterprise-level banking systems go through rigorous change management, quality assurance testing, and centralized version control before any code change reaches production. EUCs skip all of that.
Why EUCs Are a Serious Risk
The core problem is straightforward. When one person builds a tool, enters the data, and validates the output, there is no independent check on any of those steps. That collapse of segregation of duties is what regulators worry about, and the exposure breaks into several categories that compound each other.
Operational risk is the most immediate concern. Complex spreadsheets with undocumented formulas are prone to calculation errors that can misstate financial performance or capital adequacy. A formula that divides by a sum instead of an average, or a copy-paste error that drops a row of data, can distort risk figures by billions of dollars. JPMorgan Chase learned this in 2012 when its Chief Investment Office’s Value-at-Risk model, built on a series of manually operated Excel spreadsheets requiring copy-and-paste data transfers, understated the portfolio’s risk and contributed to trading losses exceeding $6 billion.
Data integrity risk compounds the operational exposure. The origin and transformation history of data flowing into an EUC is often untraceable. When a regulator asks how a number in a capital report was derived, the bank needs to show every step from source system to final output. If that chain runs through an undocumented spreadsheet maintained by someone who left the firm two years ago, the bank has a compliance problem it may not be able to fix quickly.
The aggregate effect is compliance risk. Regulators expect clear data lineage, independent validation, and documented controls for any tool that feeds financial or risk reporting. An uncontrolled EUC can trigger enforcement actions, consent orders, or findings of material weakness in the bank’s internal controls over financial reporting.
What Regulators Expect
No single rule is labeled “the EUC rule,” but the expectations line up clearly across several overlapping frameworks.
SR 11-7 and OCC 2011-12
The Federal Reserve’s SR 11-7 defines a “model” as any quantitative method that applies statistical, economic, financial, or mathematical theories to process input data into quantitative estimates. That definition covers tools used for risk measurement, capital adequacy assessment, stress testing, regulatory reporting, and valuation of exposures or positions. A complex spreadsheet that prices a derivative or calculates a risk-weighted asset figure fits within it.1Federal Reserve Board. SR 11-7 Guidance on Model Risk Management
The OCC’s companion bulletin, OCC 2011-12, names the problem directly. It states that “user-developed applications, such as spreadsheets or ad hoc database applications used to generate quantitative estimates, are particularly prone to model risk.”2Office of the Comptroller of the Currency. OCC 2011-12 Sound Practices for Model Risk Management That sentence has driven much of the industry’s investment in EUC governance over the past decade.
Together, these documents require banks to independently validate models, document their development and assumptions thoroughly enough that an unfamiliar party can understand them, and conduct ongoing monitoring to evaluate whether changes in market conditions or business activities require the model to be adjusted or replaced. Validation must be performed by people who did not develop the model and have no stake in its outcome, though some validation work done by developers must be critically reviewed by an independent party.3Board of Governors of the Federal Reserve System. Supervisory Guidance on Model Risk Management (SR Letter 11-7) – Section: Independent Validation
BCBS 239
The Basel Committee’s Principles for Effective Risk Data Aggregation and Risk Reporting (BCBS 239) address EUCs by name. Principle 3, covering accuracy and integrity, states that when a bank relies on manual processes and desktop applications like spreadsheets and databases, 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.” The same principles require banks to document all risk data aggregation processes, whether automated or manual, and to explain the appropriateness of any manual workarounds and describe their criticality to accuracy.4Bank for International Settlements. Principles for Effective Risk Data Aggregation and Risk Reporting
The Basel framework separately requires banks to maintain effective internal policies, processes, systems, and controls to ensure appropriate risk weights are assigned, and banks must be able to demonstrate to supervisors that their due diligence analyses are appropriate.5Bank for International Settlements. CRE20 Standardised Approach Individual Exposures When those risk-weight calculations run through spreadsheets, the EUC governance framework is what makes that demonstration possible.
Sarbanes-Oxley Section 404
For publicly traded banks, Sarbanes-Oxley Section 404 requires management to assess the effectiveness of internal controls over financial reporting. Spreadsheets and other user-developed tools that feed financial statements fall within the scope of that assessment. If an EUC used to calculate a material balance or adjustment lacks adequate controls, external auditors can flag it as a control deficiency or, in serious cases, a material weakness. A bank may have sound controls over its core systems and still receive an adverse finding because of an uncontrolled spreadsheet that touches a significant account balance.
How Banks Control EUC Risk
Effective governance starts with senior management endorsement and a written policy that defines what qualifies as an EUC, who is responsible for each one, and how controls scale with risk. Without that foundation, individual business lines tend to develop inconsistent practices that satisfy no one during an exam.
Responsibility is split across three roles. An EUC owner, usually a business-side manager, is accountable for the tool’s purpose, accuracy, and continued relevance, and decides whether it should continue operating or be retired. An EUC developer builds and maintains the spreadsheet, script, or database, but cannot also serve as the final approver of changes to it. An independent EUC reviewer validates the tool’s logic, tests its outputs, and confirms that controls are functioning. Independence here means someone who was not involved in building or running the tool. That separation is the single most important control in EUC governance, because it directly addresses the segregation-of-duties weakness regulators consistently identify.
Criticality Classification
Not every spreadsheet needs the same level of oversight. A one-time analysis that informs a single meeting is different from a pricing model that runs daily and feeds regulatory capital reports. Banks typically classify EUCs into high, medium, and low risk tiers based on factors like the potential dollar impact of an error, whether the output feeds regulatory filings, and how many business units depend on it.
High-risk EUCs require stringent documentation: business requirement specifications, a control procedure manual, and enough detail that an independent third party could replicate the tool’s function and output. Low-risk EUCs may need only a peer review and basic documentation of purpose. The classification itself should be reviewed periodically, because a tool’s importance can change as the business evolves.
Inventory, Controls, and Recertification
You cannot control what you have not found. Large banks can have thousands of spreadsheets and scripts scattered across shared drives, individual desktops, and cloud storage, so the first practical step is a systematic scan to identify them all. The inventory also needs a mechanism for staying current, since new EUCs are created constantly and old ones become obsolete. A one-time scan that is never refreshed becomes useless within a year.
Controls then scale with the classification. High-risk EUCs warrant strict access restrictions, centralized version control so every change is tracked and reversible, and formal input validation to catch data errors before they propagate through calculations. Medium-risk tools may require version control and periodic review without the full documentation package. Low-risk EUCs may need only a recorded peer review confirming the tool works as intended.
Critical EUCs then need periodic recertification, where an independent reviewer tests the logic, checks outputs against known benchmarks, and confirms the tool still serves its intended purpose. SR 11-7 frames ongoing monitoring as a continuous obligation, not a one-time event, and expects banks to compare model outputs to actual outcomes and assess reasons for any observed variation.6Board of Governors of the Federal Reserve System. Supervisory Guidance on Model Risk Management (SR Letter 11-7) – Section: Outcomes Analysis If a recertification review reveals problems that cannot be fixed, the tool should be retired and its function absorbed into an enterprise system or replaced. Regulators generally expect the number of high-risk EUCs to decline over time as mature, business-critical spreadsheets migrate onto IT platforms with built-in change control, access management, and audit trails.
AI-Generated Code and Newer Tools
Generative AI tools capable of writing spreadsheet formulas, Python scripts, and database queries are adding a new dimension to EUC risk. When an analyst uses an AI assistant to generate a pricing formula or automate a data transformation, the result is still an EUC, but the person who requested it may not fully understand the logic it contains. The traditional assumption that the developer understands the tool breaks down.
No federal banking regulator has issued guidance specifically addressing AI-generated EUCs as of early 2026. The White House released a nonbinding National Policy Framework for Artificial Intelligence in March 2026, but it focuses on broad legislative recommendations rather than banking-specific controls. Existing frameworks like SR 11-7 and BCBS 239 still apply: a model is a model regardless of whether a human or an AI wrote the formula. Banks expanding their use of AI coding tools should consider whether their EUC governance frameworks adequately address tools where the developer cannot explain every line of the underlying logic.