There is a paradox at the heart of banking technology: the better it works, the less visible it becomes. When a customer transfers money and it arrives instantly, they do not think about the systems that made it possible.
When a customer checks their balance at midnight, they do not consider the infrastructure running behind the screen. When a payment clears on a Sunday, customers do not typically think of the architecture that made the banking service available on a weekend.
Technology in banking is noticed almost exclusively when it fails. The rest of the time, it is invisible, and that invisibility is the goal.
The measure of a bank’s technology is not whether its systems ever fail, because every complex system fails eventually. The true measure is whether the customer ever feels it.
Banking amidst changing expectations
A decade ago, banking in Ghana operated on the assumption that certain things took time. Transfers between banks could take a day or more. To perform most transactions, you would inevitably need to visit a bank branch. Systems had maintenance windows, and customers understood (or at least accepted) that access was not continuous.
That world no longer exists; the rise of real-time payment infrastructure has fundamentally altered what customers expect. Digital banking platforms now promise access at any hour, from any location, on any device.
These capabilities, introduced as innovations, have quickly become baseline expectations. A customer who sends money today does not marvel that it arrives in seconds. In fact, they would be alarmed if it did not. The window of tolerance for delay and for the phrase “the system is down” has effectively closed.
This shift changes how banks must think about technology. The standard is now continuity: the ability to deliver critical services without interruption, and when interruption occurs, to resolve it before the customer is affected. To meet that standard, banks need to take a fundamentally new approach to how their systems are designed, not just how they are maintained.
Designing for failure, not against it
The instinct in most organisations is to try to prevent system failure, invest in better hardware, strengthen security, and eliminate vulnerabilities. These efforts matter, but they rest on an assumption that is ultimately false: that failure can be avoided entirely.
It cannot. Hardware degrades, software contains flaws that only appear under conditions no one anticipated, power grids are unreliable and cyber threats often evolve faster than defences. Even third-party providers experience their own disruptions. The question, therefore, is not whether something will go wrong, but how it is contained when it does.
The principle behind the shift I am describing is ‘Resilience by Design.’ Not the absence of failure, but the confinement of its effects. When this is done well, even significant disruptions do not affect the customer. Their payments still clear, balances remain accurate, and access is uninterrupted.
How Resilience by Design works in practice
Let us apply the concept of “Resilience by Design’ to infrastructure. A bank that runs its digital services from a single data centre has created a single point of failure, no matter how robust that facility may be. The same is true of a bank that builds entirely on one cloud provider. ‘Resilience by Design’ means distributing workloads across multiple locations and multiple providers, so that a disruption in one environment is absorbed by another. It also means retaining the ability to move between environments, rather than becoming dependent on a single vendor. The goal is not just uptime but continuity on the bank’s own terms.
Now consider the digital perimeter. Every new channel a bank opens, whether a mobile application, a fintech partnership, or a payment platform connection, creates new capabilities for customers but also becomes a potential entry point for threats. ‘Resilience by Design’ here means treating every connection as potentially compromised. No user, device, or internal system should be considered trustworthy by default; every access request must be continuously verified.
The Bank of Ghana has reinforced this approach at a sector level through its Cyber and Information Security Directive and the Financial Industry Command Security Operations Centre, which enables banks to share threat intelligence and coordinate responses. Within individual institutions, this discipline prevents a growing digital surface from becoming a vulnerability.
Finally, consider the people who operate these systems. A bank may design its technology for failure and still find itself unable to recover if critical knowledge is concentrated in a few individuals. When the one person who knows how to restore a service is unavailable during a crisis, the architecture becomes irrelevant. ‘Resilience by Design’, when applied to people, means cross-training, documented recovery procedures, and running crisis simulations regularly, not just as a compliance exercise, but as genuine preparation for potential scenarios.
What the customer should never have to think about
There is a version of this article that could go deeper into the technical architecture: the specifics of active-active configurations, containerisation, microservices orchestration, immutable backups. These are the building blocks, and they matter to the professionals who design and maintain them.
They should not matter to customers. The customer’s relationship with their bank’s technology should be one of quiet confidence. The money moves, systems work, access is reliable, and problems, when they occur, are resolved before they become visible.
Technology teams in banking often seek recognition for the complexity they manage, and that instinct is understandable. The work is genuinely demanding, and the stakes are high. Yet the highest compliment a technology function can receive is not admiration for its sophistication. It is the customer’s complete unawareness that anything complex is happening behind the scenes.
