Should we register our CRO's napkin?

End User Computing (EUC) items exist in every bigger organization and are a potential source of headaches and significant loses. So, what are EUCs and how do we save ourselves this trouble? Here’s my point of view based on our recent case.

Imagine that the bank's Chief Risk Officer (CRO) has his very own decision algorithm written on a napkin lying on his office desk. Certainly, no one else in the organization is aware of this "algorithm". What happens when the algorithm becomes invalid and the CRO makes unintentional mistakes? 

We definitely want to keep this napkin algorithm in production because it's useful. But doesn’t it make sense to let someone from the legal department, accounting, and perhaps internal audit have a look at the napkin from time to time and confirm that it doesn't represent any potential problem?

You might say this example is an exaggeration, and you’re probably right. But in banks, insurance companies, and bigger corporations, thousands of such "IT napkins", officially termed EUCs, exist in the form of Excel spreadsheets. These EUCs often contain sophisticated logic maintained by users. These files are copied, modified, and repeatedly reshared by emails or similar means. Potential mistakes from incorrect use could be seriously harmful for the organization.

Minimise the risk by knowing it

So how can we mitigate potential risks coming from EUCs spread among the entire firm? A good start is to learn which data and which EUCs are floating around. The next step is then to create an inventory of the EUCs into a unified database. During this step, it is a good idea to also categorize your EUCs by the following criteria:

• which input data is used by the EUC,

• who the owner of the EUC is,

• where the master record is stored,

• how the results are further processed and

• most importantly, estimation of the risk connected to a potential error caused by the incorrect use of the EUC

This last item is one of the most important ways you should categorize your EUCs as it allows the breakdown of EUCs into several risk tiers. 

Classification of the EUCs by risk gives us the possibility to prioritize items with potentially high impact. Higher tiers require periodic reviews to determine whether the formulas are still correct, inputs are still relevant, and, importantly, that only the latest valid version is being used. 

For example, consider an MS Excel file containing TO DOs and notes from the project manager and a quarterly report for a regulator. An incorrect version of the first one could cause short term organizational chaos, but the second could cause major and monetary consequences, meaning the quarterly report has a much higher potential impact than the notes.

The risk-tiering algorithm is typically sourced by several variables such as the last validation date or the date of the last validation of all the EUCs inputs. In later stages of the inventory implementation, it’s possible to adjust the risk tier automatically and let the system create notifications about the need for manual review of a particular EUC.

Unfortunately, only in very few cases is it possible to use automated methods of performance or backtesting, for example in the case of predictive credit risk models.

To be effective, your inventory should at the very least be able to track the time since the last validation and track changes in the EUC marked as relevant inputs. Permanent calculation of an internal risk score should also be in place. The EUC's internal risk score rising above a defined threshold should trigger these actions:

• assign a warning flag to the EUC presentable on risk dashboards

• create a validation workflow and assign tasks to a corresponding responsible team

• send emails

• contact an external system via API - for example create a Jira issue

In reality, most of the EUCs lying around belong to the low-risk tier, and there is no need to periodically check their correctness or accuracy. But the potential damage coming from the elite group of high tier ones will sooner or later require taking company-wide action.