EUC, or end-user computing, has been around for decades. But lately it's become one of those topics that keeps showing up in boardrooms and audit committees, particularly in financial services and insurance.
The reason is simple: employees have been building their own tools for years, and most organizations have no idea how much risk is sitting inside those files.
Here's what EUC actually is, why it's a headache, and what can be done about it.
What is EUC?
EUC refers to applications and tools that employees create or install on their own machines, outside of formal development processes. These tools typically get set up by local IT at a user's request, or they're part of the standard desktop build everyone gets on day one.
The most common EUC culprit? Microsoft Excel. Employees across every function use it for modeling, calculations, scenario testing, reporting — you name it. If there's a business process that needs to happen and IT has a six-month backlog, someone is going to build it in a spreadsheet. That's not a guess. That's just how organizations work.
And honestly, these tools exist for good reason. They help people move faster without waiting on overstretched IT teams or grinding through procurement. For power users in financial institutions, that could mean running complex pricing analyses, building underwriting models, or stress-testing data scenarios on their own timeline.
But they come with their own challenges. Those same tools almost never have version control, formal testing, audit trails, or security oversight.
Why is EUC such a challenge?
The low-code and no-code movement has poured fuel on this fire. Tools that used to require a developer now come with drag-and-drop interfaces anyone can pick up. That's great for productivity. It's less great for governance.
Even before low-code, employees could build surprisingly complex solutions in Excel and Access. The difference now is scale. More people are building more things, faster, with less oversight. And most of it never touches the IT department.
Here's where the risk builds up:
-
No governance over IP. Logic built in spreadsheets and local apps often isn't documented, reviewed, or stored centrally. When the person who built it leaves, the knowledge walks out the door with them.
-
No audit trail. Decisions driven by spreadsheet outputs may not be traceable. For regulated firms, this isn't a theoretical concern — it's a compliance exposure with real teeth.
-
No formal testing. These tools rarely go through any kind of QA. Errors can sit undetected for months. Sometimes years.
-
Human error under pressure. Tight deadlines and reporting demands are exactly the conditions where mistakes in manually maintained files are most likely — and most costly.
-
Security gaps. Files are often unencrypted, shared over email or chat, and stored wherever is most convenient rather than most secure.
None of this makes EUC tools inherently bad. They fill a real gap. But without controls around them, they quietly become one of the largest sources of operational risk in an organization.
Why is Excel always at the center of this?
Because Excel might be the most versatile data tool ever created. It's been a fixture in nearly every company on the planet since 1985, and it's earned that position.
Its superpower is accessibility. Someone can go from tracking monthly expenses to building a sophisticated underwriting model, a regulatory reporting tool, or a back-testing framework — all within the same application. No deployment process. No code review. No permission needed.
Which is also exactly the problem.
Excel was never designed to be an enterprise application platform. It has no built-in version control, no audit logging worth mentioning, and no native testing framework. Files (often unencrypted) get copied, emailed, saved to shared drives, and edited by multiple people with no clear record of what changed, when, or by whom.
For any company, that's a concern.
For financial institutions — where spreadsheet outputs can feed directly into regulatory filings, pricing decisions, and risk assessments — it's a material one.
People love to complain about Excel, but the reality is more nuanced: it's both indispensable and dangerous. You can't get rid of it. You have to govern it.
How can organizations address EUC risk?
Not by banning spreadsheets. That's been tried. It doesn't work.
The practical path is systematic monitoring, control, and governance layered on top of the tools people already use. That means:
-
Clear policies for how employees adopt and use desktop EUC tools — what's allowed, what needs review, and where the boundaries are.
-
Documentation standards for logic that drives business decisions. If a spreadsheet feeds into pricing or regulatory reporting, the logic inside it needs to be reviewable by someone other than the person who built it.
-
A transparent path to formal development for when a spreadsheet outgrows its original purpose. Every organization has that one file that started as a quick calculation and is now load-bearing infrastructure. There needs to be a clear process for graduating those tools into something properly governed.
For organizations thinking about citizen development more broadly, Noel Carroll's whitepaper on Shell's approach to "DIY Development" is a solid read. It covers how Shell brought citizen development inside their enterprise governance framework rather than trying to stamp it out.
But the harder, more specific question remains: what do you do about the spreadsheets that already exist — the ones running critical processes today, right now, without proper controls?
How Coherent Spark addresses EUC challenges
Coherent Spark is the leading response to common EUC problems facing financial institutions in both banking and insurance.
Rather than asking teams to rip out Excel, our platform wraps governance, auditability, and performance around the spreadsheets they already depend on.
Here's what that looks like in practice:
Version control from the moment you upload
Drop an Excel file into Spark and you've created version one of a managed service. You get a central repository where you can update your files with release notes and, if there’s an issue, retrieve a previous version. No more guessing which copy of "model_v3_FINAL_revised2.xlsx" is actually current.
Your Excel logic, exposed as an API
Spark converts your spreadsheet logic into a secured API endpoint over a standard REST connection. That means other systems — your CRM, policy admin platform, reporting tools — can call that logic directly. The spreadsheet stops being a siloed desktop file and becomes a reusable service that other applications can plug into.
Behind the scenes, Spark compiles your spreadsheet into what we call a Neuron: a compiled version of your logic that runs significantly faster than native Excel. This matters when you need to execute that logic against large datasets or handle high transaction volumes.
Built-in testing that actually scales
Spark's Test Center lets you run large test datasets against your spreadsheet logic. Upload test data manually, use templates, or let the system generate test cases across data ranges. Tests run fast, are repeatable across versions for regression testing, and are fully logged. You can finally answer the question: "does this spreadsheet still produce the right outputs after the last round of changes?"
Full audit logging, down to the transaction
Every API call gets logged with timestamps, input data, output data, and a downloadable copy of the spreadsheet state that was executed. If an auditor asks what numbers were used for a specific transaction, you can show them exactly what happened, when, and with what inputs. Not a reconstruction — the actual record.
Beyond Excel-to-API: seeing the full picture
Spark solves the problem of taking a single spreadsheet and making it governed, testable, and reusable. But most organizations aren't dealing with one spreadsheet. They're dealing with hundreds or thousands, scattered across teams and business lines, with no central inventory and no way to assess which ones carry the most risk.
That's the problem Coherent's Insights and Control are built for.
Insights maps your entire EUC environment — flagging hidden files, risky dependencies, and complexity that would otherwise stay buried.
Control adds the scalable governance layer: versioning, permissions, approval workflows, and immutable audit trails that bring spreadsheets into the same framework as your enterprise systems.
If Spark is how you fix a specific spreadsheet, Insights and Control are how you get your arms around the whole problem.
Where this leaves you
EUC risk isn't new. But it's one of those problems that's easy to deprioritize until it isn't — until a regulator asks a question you can't answer, or a key spreadsheet breaks and nobody knows how it worked in the first place.
Spreadsheets are deeply embedded in critical business processes, and that's not going to change. The question isn't whether your organization uses Excel. It's whether you have the governance, auditability, and testing infrastructure to use it responsibly.
