End User Computing Tools fill the gaps
In banking circles, End User Computing tools or EUCs are often framed as a risk to eliminate rather than a reality to manage. Spreadsheets, Access databases, Power Apps, and local scripts are typically grouped under “EUC risk,” discussed through remediation plans, inventories, and controls. The implied assumption is that with enough discipline, EUCs would not exist. That framing misses the real reason they persist.
Banks are complex environments where data moves across desks, systems, and regulatory expectations that change faster than core platforms can adapt. When practitioners need answers quickly, they build practical solutions to fill the gaps formal systems leave behind. That is how EUCs emerge. Not as workarounds born of negligence, but as necessary tools tied directly to how work gets done. Pretending these tools should not exist does not reduce risk. It pushes critical activity into places leadership cannot see or support.
What I saw working with GSIBs
My own perspective on this comes from working with GSIBs addressing MRIAs. In that context, EUCs were not fringe tools. They were central.
Teams responsible for data lineage, controls, and regulatory responses were expected to answer detailed questions quickly and accurately. In practice, the official tools often fell short. Vendor data governance platforms lacked the flexibility, interdependency views, or real time feedback practitioners needed. Internal tools were rigid, slow to adapt, or simply didn’t model the work as it was actually done.
The most valuable contributions I often made came from building well governed EUCs.
These were not wild spreadsheets passed around by email. They were structured, controlled tools. Inputs validated row by row in real time. Clear ownership. Traceable logic. Explicit links to upstream data. Practitioners could move fast and with confidence.
Why forcing everything into tools doesn’t work
A common response to EUC risk is to mandate usage of centralized platforms. In theory, this sounds reasonable. In practice, it often fails.
When tools don’t reflect how people actually work, they create friction. Practitioners still need to do the work, so they rebuild the missing pieces elsewhere. Now the risk hasn’t gone away, it’s just gone dark.
3rd party vendor platforms often assume a world where definitions are settled, workflows are linear, and change is rare.
The environments responding to regulatory findings don’t look like that. They need flexibility, iteration, and speed.
A better way to think about EUCs
The more effective banks we’ve worked with don’t ask how to eliminate EUCs. They ask how to govern them intelligently. That starts by accepting a few realities.
Some EUCs are exploratory and low risk. Others are material and deserve tighter controls. Not everything needs enterprise grade engineering, but important things need more than good intentions.
Governance becomes practical when EUCs consume data from authorized sources, rather than defining truth themselves. When transformations live upstream and EUCs focus on inspection, analysis, and decision support. When ownership is explicit and lineage is traceable.
In that model, EUCs stop being uncontrolled systems and start being governed interfaces.
The role companies like ours play
This is where firms like ours fit naturally.
We don’t approach EUCs as something to stamp out or blindly rebuild. We approach them as artifacts of real work. They tell us where official systems fall short and where value is actually created.
Our role is to help banks put structure around that reality. To turn fragile EUCs into governed ones. To decide what should stay flexible, what needs guardrails, and what truly belongs in a more durable architecture.