The Most Dangerous System in Your Bank Runs on Excel

“The spreadsheet is the most dangerous piece of software ever created.” — Daniel Lemire

---

There is a system in your bank that nobody calls a system. It has no documentation. It has no change management process. It has no backup strategy, no disaster recovery plan, and no access control beyond the fact that one person knows the password to the folder on the shared drive.

It processes regulatory data. It generates board reports. It calculates risk figures that are submitted to the financial supervisory authority.

It is an Excel file with macros. And the person who built it is either about to retire or has already left.

If you work in data warehousing for European banks — and I have done so for over 20 years — you know exactly what I am describing. You have seen it in every institution. Not as an exception. As a rule.

---

How It Happens

Nobody sets out to build critical infrastructure in Excel. It starts innocently. A business analyst needs a report that IT cannot deliver for another six months. The analyst builds it in Excel. It works. Management is satisfied. The report becomes a recurring deliverable.

Over the next two years, the spreadsheet acquires macros. It pulls data from three different sources via copy-paste. Someone adds a VLOOKUP that references another workbook on a different share. A pivot table is added for the monthly board presentation. A colleague adds conditional formatting so the risk figures turn red when they exceed a threshold.

By year three, it is no longer a spreadsheet. It is an application. It has business logic, data integration, transformation rules, and output formatting. It has everything a proper ETL pipeline has — except version control, testing, documentation, audit trails, and the ability to function when its creator is unavailable.

In the regulated world, this is not merely inconvenient. It is a compliance risk.

---

The Audit Problem

Regulators do not care whether a number was produced by a data warehouse or a spreadsheet. They care whether the process that produced it is documented, reproducible, and auditable.

A properly designed data pipeline satisfies this requirement. The process is defined in code. The code is version-controlled. The execution is logged. The output is traceable.

An Excel macro satisfies none of these requirements. The logic is embedded in cells and VBA modules that are opaque to anyone who did not build them. There is no execution log. There is no version history beyond “Final_v3_FINAL_edit_NEW.xlsx” saved on a network drive. When the auditor asks, “How was this number calculated?” the answer is frequently, “We need to ask Gerhard, but he is on holiday.”

I have personally witnessed audit findings in European banks where the root cause was an undocumented Excel process that produced numbers for regulatory reporting. The remediation was not a technical fix. It was a project.

---

Why IT Cannot Solve It Alone

The standard response from IT departments is: “Put it in the data warehouse.” This is correct in principle. But it ignores reality.

The business analyst built the Excel solution because IT could not deliver on time. If IT now says, “Give us 12 months, and we will rebuild it properly,” the business hears the same message that caused the problem in the first place. The analyst will nod, agree, and continue using Excel.

The gap is not technical. It is organisational. Business teams need autonomy over their data processes. IT needs governance and control. These two requirements are in tension, and Excel has been the unofficial resolution for decades — a resolution that works until it does not.

What is needed is a middle ground: tools that give business teams the autonomy to manage their own data workflows and reporting, while enforcing the governance, auditability, and structure that regulators and IT require. This is not a new data warehouse. It is the layer between the data warehouse and the business user — the layer where Excel currently sits, unsupervised.

---

The Cost of Doing Nothing

Banks that tolerate Excel-based critical processes are accumulating risk in three dimensions:

Operational risk. A key person leaves, becomes ill, or simply makes a copy-paste error. The process breaks. The board report is delayed or incorrect. This happens more often than any CIO will publicly admit.

Regulatory risk. An auditor identifies an undocumented, non-reproducible process in a compliance-relevant data chain. The finding triggers a remediation project that costs more than the proper solution would have cost in the first place.

Efficiency loss. Senior analysts — people who should be analysing data — spend hours each month manually assembling, formatting, and distributing reports. This is not value creation. It is data logistics performed by the department’s most expensive people.

---

A Practical Alternative

I have recently come across a company that addresses exactly this problem. ETIXPERT is a specialist for data-driven process automation in regulated industries — banking, insurance, and industrial organisations — with over 25 years of experience.

They offer two platforms that directly replace the Excel-based workflows I have described:

Zagreus is a server-side workflow and reporting engine. It automates the generation and distribution of reports (PDF, Excel) in a fully audit-proof manner. It eliminates macros, manual distribution lists, and the kind of shadow IT that accumulates when business teams solve problems on their own. The entire execution is server-side — no client-side macros, no local dependencies. It integrates with SharePoint, Jira, Power BI, and other enterprise tools.

niota is a low-code data platform for business teams. It allows departments to manage structured data and workflows with built-in governance — role-based access, multi-tenancy, and full traceability. It gives the business the autonomy they need without sacrificing the control IT requires. It is designed specifically for regulated environments and dynamic processes where data quality and auditability are non-negotiable.

I want to be transparent: I mention them here because their solutions directly address a problem I have observed in nearly every banking and insurance project I have worked on. The recommendation is based on relevance to the topic, not a commercial obligation.

---

The Question to Ask

If you work in a European bank — or any regulated institution — ask yourself this: how many critical processes in your organisation currently depend on an Excel file that one person maintains?

If the answer makes you uncomfortable, that discomfort is the correct response.

The data warehouse handles the heavy lifting. But the last mile — where data becomes reports, decisions, and regulatory submissions — is where Excel still reigns. And it is where the risk sits.

Fixing the data warehouse is important. Fixing the last mile is urgent.

---

Roland Wenzlofsky is the founder of DWHPro, a Vienna-based data warehouse engineering consultancy and official partner of PwC Austria. He is a Teradata Certified Master with over 20 years of experience in enterprise data warehousing across the European banking, insurance, and telecom sectors. He is the author of “Teradata Query Performance Tuning” and writes about the reality of data engineering at dwhpro.com.

---

Written by Roland Wenzlofsky, founder of DWHPro and author of Teradata Query Performance Tuning. DWHPro has helped data warehouse practitioners for 15+ years.