Introduction

Banks are facing the challenge of using Individually Developed Applications (IDV) flexibly while complying with increasingly strict regulatory requirements. IDV – often referred to as End-User Computing (EUC) – includes any tools developed or maintained by business units themselves, such as Excel spreadsheets, Access databases with VBA, or scripts written in Python or R. These tools are indispensable in day-to-day banking operations but carry inherent risks. Studies show that 94% of Excel spreadsheets used for business decision-making contain errors, leading to poor decisions and financial loss. At the same time, regulators like BaFin are increasingly demanding control over this so-called “shadow IT.”

This article outlines how banks can continue to use Excel, Access, Python, or a combination of these tools to develop powerful IDV solutions and how IT departments can enable business teams to work effectively without falling afoul of regulatory obligations.

Excel/Access vs. Python: Strengths and Weaknesses

Excel and Access (with VBA) have long been the go-to tools for business users in banks. Their main strengths are ease of use, familiarity, and flexibility. Business users can build ad-hoc reports or calculators quickly without involving central IT. Excel is great for interactive calculations and pivot analysis, while Access enables light-weight relational data management. VBA macros allow automation directly within these environments. The key benefit: rapid, user-controlled implementation of solutions.

However, they also have major weaknesses: Complex Excel models can become opaque, hard to audit, and error-prone. Access databases may grow into unmaintainable silos. Most of all, control mechanisms such as versioning, change tracking, and documentation are often missing, making it difficult for auditors or IT to verify accuracy or compliance.

For critical processes—such as regulatory reporting or large financial calculations—this lack of governance is a regulatory red flag.

Python, and tools like R or MATLAB, offer a more modern and scalable approach. Python excels at data wrangling, automation, and advanced computation, with rich libraries like Pandas and NumPy. It supports clean code structure, testing, and integration with databases and APIs. While not every business user is a programmer, Python allows better reusability, scalability, and easier transition to IT-maintained systems.

However, Python scripts created by business users still count as IDV/EUC and are therefore subject to the same controls as Excel models. Risks include inconsistent environments, undocumented logic, and lack of audit trails—particularly if code is executed locally without IT support.

Hybrid Approaches

In many cases, the best approach is not “Excel or Python” but both. Excel can act as a user interface, while Python runs complex data processing in the background. Python can read and write Excel files, making integration seamless. New features in tools like Microsoft 365 (e.g. Python in Excel) highlight this synergy.

In short:

  • Use Excel/Access for quick prototyping, interactive use, or one-time analyses.
  • Use Python for recurring processes, complex logic, and larger data volumes.
  • Combine them for best results—flexibility plus control.

Regulatory Framework: What DORA, MaRisk, and Others Require

Regulators across the EU have turned a sharp eye on IDV solutions. With the Digital Operational Resilience Act (DORA) coming into force in 2025, all IT systems—including those developed by business users—must meet strict operational and security standards.

In Germany, this is reinforced by:

  • MaRisk (Minimum Requirements for Risk Management): Requires reliable data aggregation and clear control structures.
  • BAIT (Bank Supervisory Requirements for IT): Explicitly includes business-developed applications in its scope. Requires a software inventory, coding standards, testing, and risk classification—even for Excel tools or Access databases.
  • BCBS 239: Pushes for strong data quality and governance in risk data aggregation.
  • SOX (for listed entities): Brings IDV applications used in financial reporting under internal control audits.
  • GDPR: Applies to any IDV handling personal data.

In short: Excel spreadsheets or Python scripts built in business units are no longer outside the scope of regulation. They must be documented, tested, risk-assessed, and secured—just like any other application.

The Role of IT: Governance as an Enabler

How can IT departments support business users while meeting regulatory demands? The key is structured governance that doesn’t block flexibility, but enables it safely. A smart IDV governance framework includes:

1. Clear IDV Policy & Training

Banks should define a formal IDV/EUC policy, covering:

  • What counts as an IDV tool
  • Roles and responsibilities
  • Lifecycle management and change control
  • Classification by risk

Training and awareness are essential. Business users should understand what’s allowed, when to involve IT, and how to mitigate risks (e.g. peer review, avoiding complex Excel formulas).

2. Inventory and Risk Classification

All existing and new IDV tools should be:

  • Registered (with purpose, owner, input/output)
  • Classified by criticality (impact on confidentiality, availability, integrity)
  • Reviewed regularly, with more controls for higher-risk tools

3. IT-Supported Enablement

Rather than policing business users, IT can offer tools and support:

  • Templates for Excel or Python with built-in validations
  • Excel add-ins for error checking or compliance tagging
  • Central version control systems (e.g. Git for Python scripts)
  • Secure execution environments (e.g. virtual machines, containers, or cloud workspaces)
  • Standard environments (e.g. approved Python packages, controlled Excel versions)

4. Operational Support & Resilience

Critical IDV tools should:

  • Be hosted on central servers or platforms (e.g. SharePoint)
  • Include access management and backups
  • Be covered by incident and disaster recovery plans

This aligns with DORA’s focus on operational resilience, even for user-built tools.

5. Monitoring & Audit

Governance must include ongoing oversight:

  • Periodic reviews by internal audit or risk management
  • Dashboard reporting of critical IDV use
  • GRC integration to link IDV risk into overall operational risk

With this approach, business users stay empowered, while IT ensures regulatory and security compliance.

Value for Business Teams

Despite stricter governance, IDV tools remain hugely valuable for business users. They enable:

  • Faster problem solving without waiting for full-scale IT projects
  • Tailored solutions based on deep business knowledge
  • Innovation, especially when paired with IT support

When done right, IDVs can act as prototypes or interim tools for future IT implementations. Business users learn to build smarter tools, and IT gains insight into emerging business needs.

The regulatory framework should not be seen as a blocker but as a guide. With the right controls, banks can achieve both innovation and compliance.

Conclusion

Excel or Python? For IDV in banks, the answer is: both—with the right governance.

Excel and Access are ideal for quick, user-driven analysis; Python brings scalability and professionalism. Together, and under a clear framework of policies, inventories, testing, and IT support, they allow business teams to innovate safely—even under DORA, MaRisk, and BAIT.

Banks that master this balance will empower their teams, satisfy regulators, and create long-term value through flexible, compliant data-driven processes.