Operational Risk in Software
What Banking Executives Need to Understand About Technical Debt
Technical debt is a term that surfaces frequently in engineering retrospectives and quarterly planning sessions. In banking, it rarely receives the same level of attention in risk committees. That is a governance gap — and one with measurable consequences.
For CTOs and VPs of Engineering leading technology functions at banks and payment institutions, technical debt is not a development backlog item to be managed at team level. It is an operational risk category with direct exposure to system availability, regulatory compliance, and audit outcomes. Framing it as such is not a rhetorical exercise; it is a prerequisite for securing the investment and organisational priority that remediation actually requires.
What Technical Debt Looks Like in a Banking Context
Technical debt accumulates in layers. At the foundation, most established banks carry core banking systems built on COBOL or early-generation Java platforms, extended over decades through undocumented workarounds, custom integrations, and hardcoded business logic embedded in places that make change expensive and risky.
Above that layer sit middleware components, API gateways, and other applications added during digital transformation efforts — often integrated without full understanding of the underlying system's constraints. The result is dependency chains that are poorly mapped, inconsistently tested, and difficult to modify without triggering cascading failures.
What makes this operationally significant is not the age of the code itself but what that age implies: degraded observability, brittle integrations, and an engineering team increasingly unable to predict the consequences of change.
How Technical Debt Manifests as Operational Incidents
The operational risk taxonomy already in use across banking — people, process, systems, and external events — maps cleanly onto technical debt failure modes.
System failures and unplanned outages. Aging codebases are disproportionately represented in post-review incidents. When a payment processing system goes down during peak settlement windows, the proximate cause is often an undocumented dependency or an unpatched component that no longer behaves predictably under current load conditions. The cost of a single such incident — in SLA penalties, reputational exposure, and regulatory notification obligations — frequently exceeds the annualised cost of the remediation work that would have prevented it.
Security vulnerabilities. Legacy systems often use software, libraries, and operating environments that no longer receive security patches. In a threat landscape where financial institutions are actively targeted, an unpatched vulnerability in a core transaction processing component is not a theoretical risk. Under DORA and the NIS2 Directive, the obligation to demonstrate active management of ICT risk extends to legacy infrastructure — not just modern systems.
Failed regulatory audits and submission errors. Technical debt directly impairs audit readiness. Systems without structured logging, with inconsistent data lineage, or with undocumented processing logic create material gaps when regulators or internal audit teams require evidence of how a specific decision was made or a transaction was processed. PSD2 compliance, EBA reporting requirements, and DORA-mandated ICT risk assessments all presuppose a level of system transparency that heavily indebted codebases cannot reliably provide.
Quantifying the Exposure
Technical debt is difficult to quantify precisely, but it is not impossible to bound. Three metrics are particularly useful for communicating operational exposure to non-engineering stakeholders:
Mean time to recovery (MTTR). Systems with high technical debt consistently exhibit longer recovery times following incidents. MTTR is directly correlated with the readability and modularity of the codebase — both of which degrade as debt accumulates. Tracking MTTR by system or domain over time surfaces where the debt burden is operationally active.
Change failure rate. The percentage of deployments that require a rollback or emergency patch is a leading indicator of codebase fragility. In legacy banking systems, change failure rates are often multiples of what modern engineering benchmarks would consider acceptable. Each failed deployment carries direct costs in engineering time, rollback complexity, and — where customer-facing systems are affected — potential regulatory notification.
Deferred maintenance accumulation rate. The volume of known vulnerabilities, deprecated dependencies, and outstanding security patches in a given system gives a snapshot of how quickly exposure is growing. Without active remediation, this number compounds. These metrics, expressed in operational and financial terms, provide the basis for a business case that risk committees and executive leadership can evaluate against other capital allocation decisions.
The Cost of Deferral vs. the Cost of Remediation
The most common argument against modernisation investment is cost and disruption. The risk calculus looks different when deferral costs are made explicit.
A major outage in a core payments system typically costs a European bank between €500,000 and several million euros in direct losses, regulatory penalties, and remediation — before accounting for customer attrition or reputational damage. A significant data breach affecting customer records carries GDPR exposure of up to 4% of global annual turnover. DORA non-compliance, once enforcement matures, introduces further penalty exposure alongside mandatory incident reporting obligations.
Against those figures, a structured modernisation programme — approached incrementally through strangler-fig patterns, domain decomposition, or targeted re-platforming rather than wholesale replacement — typically delivers a more predictable cost profile and measurable risk reduction at each milestone. The engineering case for incremental modernisation and the financial case for operational risk reduction are, in this context, the same argument.
Building the Business Case for Modernisation Investment
The most effective framing for a modernisation business case at executive or board level is not a technical roadmap — it is a risk register entry with quantified exposure and a mitigation cost. For a CTO or VP of Engineering, this means translating engineering assessments into the language the risk function already uses: likelihood, impact, time horizon, and residual risk after mitigation.
Attach legacy system risk to existing risk appetite statements. If your institution has defined tolerance thresholds for system availability, data integrity, or regulatory compliance, legacy codebases that demonstrably increase the probability of breaching those thresholds belong on the risk register with ownership, remediation timelines, and funding requirements explicitly assigned.
Technical debt in banking is not a problem that resolves itself through accumulated workarounds. It resolves through deliberate investment decisions made by engineering and risk leadership acting in alignment. At Oceanobe, we work with banks and financial institutions to assess legacy system exposure, define incremental modernisation pathways, and build the technical and commercial case for remediation — structured around the operational risk frameworks that banking executives already use to make decisions.
