Glossary · Technical debt
Technical debt in banking — what it is, how to measure and reduce it
Technical debt is the implicit, accumulated cost of design or implementation decisions that prioritised fast delivery over long-term sustainability. Like financial debt, it accrues interest: every change to the system becomes slower and more expensive. In banking and insurance it materialises as COBOL, mainframe, Oracle Forms, monolithic PL/SQL and batch processes. Under DORA, technical debt stops being only an engineering problem and becomes an operational-resilience risk.
Full content in Spanish. This English entry is a concise summary. The complete reference (including comparative tables, official sources and Vermont Solutions context) is available in the Spanish version: Read the full entry in Spanish →
Frequently asked
What is technical debt?
It is the implicit, accumulated cost of choosing a fast or limited solution over a more robust one. The metaphor, coined by Ward Cunningham, is financial: the debt accrues interest as higher cost and slowness of every future change. It can be deliberate (taken on knowingly, for a deadline) or accidental (the result of design erosion over time).
How is technical debt measured?
There is no single metric, but there are indicators: average time and cost to implement a change, frequency and severity of incidents, test coverage, age and support of the stack, concentration of knowledge in few people, and vendor dependency. The goal is not an absolute number but the interest: how much more expensive and slow it is today to operate and change the system because of the debt.
Strangler fig or big bang to reduce it?
The strangler fig pattern replaces the legacy system module by module, keeping it running in parallel and migrating functionality incrementally with output comparison. It is the preferred approach in banking because of its lower risk. Big bang —full replacement in a single cutover— is only justified for small systems or when coexistence is unfeasible; in core banking its risk is usually unacceptable.
Why does technical debt matter under DORA?
DORA requires operational resilience, continuity and auditability. A system with high technical debt —hard to test, observe and recover, and dependent on a vendor or a few people— raises operational risk and complicates evidencing controls to the supervisor. Reducing technical debt in critical systems is, in practice, improving the resilience posture.
English summary maintained by Vermont Solutions. Citable with attribution. Regulation evolves — verify the latest version at the official source linked in the Spanish entry. Does not constitute legal advice.