When software failures hit the banking sector, the assumption is often that cybercriminals are to blame.
But many of the incidents that interrupt customer payments, prevent users from accessing their accounts, or take online banking offline have nothing to do with malicious attacks.
They start with an internal software change.
The Basel Committee on Banking Supervision's latest report shifts the conversation toward these everyday operational failures. Based on findings from 16 jurisdictions, including the United States, the United Kingdom, Germany, Japan, Singapore, Australia, Canada and the European Union, the report examines what causes non-malicious ICT incidents and how banks are trying to prevent them.
For quality engineering teams, the findings are hard to ignore.
Many of the biggest operational risks regulators identify are the same challenges QA teams have been trying to solve for years.
The biggest failures happen after a change
The report found that the four most common root causes of ICT incidents were:
- Change control gaps
- Gaps in system design, development and testing
- System capacity and performance issues
- External dependency operational failures
Three of those four are directly connected to software delivery.
Not coding.
Not security.
Delivery.
Banks aren't struggling because developers suddenly forgot how to write software.
They're struggling because modern banking systems have become incredibly interconnected.
One release might affect hundreds of APIs, legacy platforms, cloud services and third-party providers. A configuration change that looks harmless inside one application can trigger failures several systems away.
The report even includes an example where a failed system migration disrupted banking services for roughly 10% of an entire country's population. Another incident left critical banking services unavailable for several days.
Those aren't edge cases anymore.
They're examples of what happens when critical business processes aren't fully understood before a release.
More testing doesn't necessarily reduce risk
One of the biggest misconceptions in software quality is that more tests automatically mean less risk.
The Basel Committee's findings suggest something different.
Banks already have mature change management processes.
They already perform extensive testing.
Yet change control gaps remain the most frequently reported cause of operational incidents across participating jurisdictions.
The issue isn't necessarily the amount of testing.
It's where testing effort is focused.
Running thousands of automated tests provides limited confidence if none of them validate the customer journey most likely to break during a release.
That's exactly why risk-based testing has become more important.
Instead of treating every feature equally, it starts by identifying the areas where failures would have the greatest operational, financial or regulatory impact.
Those become the priority.
The report highlights a challenge every enterprise QA team knows
One section feels particularly familiar.
Banks continue to struggle with differences between testing and production environments.
The report specifically mentions gaps in:
- test data
- system configurations
- external integrations
- security controls
These differences make it possible for software to pass every validation step before deployment and still fail in production.
It's one of the oldest problems in software testing.
And it's becoming more difficult to solve as organisations adopt cloud infrastructure, microservices and distributed architectures.
Testing a feature is one thing.
Testing how dozens of connected systems behave under real production conditions is something else entirely.
Modern banks are changing how they deploy software
The report also provides an interesting look at how banks are reducing operational risk before releases happen.
Instead of relying on large deployments, many institutions are adopting techniques such as:
- canary releases
- blue-green deployments
- feature flags
- progressive rollouts
- automated rollback
- dependency mapping
- production-like testing
These approaches all have something in common.
They reduce the blast radius.
Rather than exposing every customer to a new release immediately, banks are validating changes gradually, collecting evidence and limiting the impact if something goes wrong.
One statistic from the industry outreach illustrates how much change large organisations are managing.
A participating bank reported implementing more than five million technology changes during 2025, while reducing its failure rate through stronger automation, governance and testing practices.
That isn't about slowing releases down.
It's about making every release safer.
Third-party software has become part of your test scope
Another recurring theme throughout the report is third-party risk.
Banks increasingly rely on external providers for cloud infrastructure, identity management, payment processing, hosting, telecommunications and countless other services.
The Basel Committee even discusses nth-party dependencies. In other words, the suppliers behind your suppliers.
One case study describes a failure at a shared data centre, where changes to the cooling infrastructure caused emergency shutdowns that disrupted multiple banks at once.
You can't control every vendor.
But you can understand which business processes depend on them.
And you can test how those processes behave when external systems slow down, return unexpected responses or become unavailable altogether.
AI is helping QA teams. It isn't replacing them.
Artificial intelligence appears throughout the report, although not in the exaggerated way many headlines suggest.
Banks are already using AI to:
- detect software defects
- identify testing blind spots
- improve observability
- predict potential failures
- support software development productivity
The Basel Committee supports these use cases.
At the same time, it repeatedly stresses that human oversight remains essential.
That's an important distinction.
AI can identify patterns faster than people.
It cannot decide which business process creates the highest operational risk or whether the impact of a failure is acceptable.
Those are business decisions.
Risk-based testing is becoming an operational resilience strategy
The Basel Committee never explicitly tells banks to adopt risk-based testing.
What it does say is arguably more interesting. It encourages banks to identify critical operations, understand dependencies, strengthen change validation, improve production-like testing, expand continuity testing and focus resources where operational failures would have the greatest consequences.
That's the mindset behind risk-based testing. The objective isn't to execute the most tests.
It's to make sure the software that matters most receives the highest level of confidence before it reaches production.
As banking systems continue to grow in complexity, that approach is becoming less of a competitive advantage and more of a regulatory expectation.
Turn operational risk into a testing strategy
The Basel Committee's report makes one thing clear: the biggest operational risks aren't always the most obvious ones. They're often hidden in complex business processes, system dependencies, and software changes that traditional testing struggles to prioritise.
That's exactly what we're building with the QA Risk Agent.
Instead of asking your team to manually decide what deserves the most attention, the QA Risk Agent analyzes your application, identifies high-risk business processes, and generates risk-based test cases in minutes. It helps QA teams focus their effort where failures would have the biggest operational and customer impact.
If you're looking for a smarter way to prioritize testing instead of simply running more tests, join the waitlist today.
👉 Join the QA Risk Agent waitlist and be among the first to see how AI can help you build a truly risk-based testing strategy.
