Digital transformation has become a remarkably accommodating term. A new mobile application can qualify. So can moving workloads to the cloud, automating a few internal processes or introducing an AI-powered customer service interface.
None of these initiatives are insignificant. Customer-facing investments have transformed how people open accounts, make payments, apply for loans and access banking services without visiting a branch. The problem begins when this visible progress is mistaken for institutional transformation.
Co-Founder and Director
Josh Software
Behind every simple digital interaction is a far more complicated operational sequence. A bank may offer an elegant account-opening journey while its operations team manually reconciles information across disconnected systems. A loan application may be completed in minutes, but changing the rules that determine its eligibility could take months. Even revising a transaction limit may require coordination across the core banking platform, fraud controls, regulatory rules, customer classifications and multiple approval workflows.
In such cases, the interface has changed, but the institution’s ability to operate and evolve has not. The technology may look modern to the customer while the underlying complexity continues to surface through longer turnaround times, rising operational costs, inconsistent experiences and an enduring dependence on manual intervention.
It also makes change disproportionately expensive. What appears to be a modest business requirement can become a multi-quarter programme because several systems, vendors and departments must first be aligned. This explains why many financial institutions have invested significantly in digital transformation without becoming substantially easier to change. They have digitised customer interactions without necessarily re-engineering the systems, processes and decision-making structures on which those interactions depend.
The more useful measure of modernisation, therefore, is not how digital an institution appears. It is how quickly and safely it can change what happens behind the screen.That requires more than another collection of technology projects. It requires engineering control over the systems and business logic that determine how the institution actually operates.
Technology ownership is really about the ability to change
Financial institutions have traditionally purchased technology for good reasons. Core banking, onboarding, lending, cards and compliance are complex domains. Established products offer reliability, regulatory familiarity and a faster route to implementation.
Over time, however, separate business divisions often procure separate solutions for closely related needs. Savings, cards, loans and investments may each have their own technology stack, even when they serve the same customer and repeat many of the same processes.
The resulting problem is not simply that there are too many systems. It is that no one owns the institution’s technology landscape as a coherent whole.
A vendor may own the product roadmap. A business unit may own its immediate requirement. An operations team may own the workaround needed to keep the process running. Yet no team has sufficient control to change the complete workflow. Even a small alteration must then travel through product limitations, commercial negotiations, release schedules and competing priorities.
This is frequently described as vendor lock-in, but the deeper issue is engineering dependence. The institution may own the customer relationship and remain accountable to the regulator, while lacking meaningful control over the technology through which both responsibilities are fulfilled.
Replacing one product with another does not resolve this. It merely transfers the dependence.
Nor is the answer to build everything internally. A bank that attempts to develop every component itself assumes the hiring, retention, delivery and maintenance challenges of a technology company. That is rarely the most sensible use of its engineering capacity.
The practical answer lies between these two extremes: institutions should own the engineering that differentiates how they operate, while continuing to use reliable platforms for commoditised capabilities.
Re-engineering the layer where the institution actually operates
Between the core banking platform and the customer-facing channels sits a critical layer of business logic and operational workflows. This is where transaction limits are configured, KYC rules are applied, suspicious-account indicators are evaluated, reconciliations are managed and administrative approvals take place.
In many institutions, this logic is either embedded inside vendor products or distributed across spreadsheets, manual processes and disconnected applications. As a result, changing a business rule often requires changing the underlying product, or asking its vendor to do so.
An engineering-led approach brings this logic into a bank-owned configuration and orchestration layer. The core platform continues to perform the functions for which it was designed, while the institution controls the rules, workflows and interfaces through which those functions are used.
This is not another product to be procured. It is engineering infrastructure built around the institution’s operating model. Business rules can evolve without waiting for core-platform releases, compliance requirements can be implemented consistently, and operations teams can work through common interfaces rather than navigate multiple vendor systems.
Separating operational workflows from the core also reduces the disruption involved in upgrading or replacing an underlying system. The institution can change its technology foundations without rebuilding every customer journey or forcing operations teams to relearn established processes.
One way to build this bank-owned layer without starting entirely from scratch is through open-source technologies. They provide proven foundations that institutions can adapt to their operating requirements while retaining ownership of the resulting intellectual property and control over its future development. Commercial platforms will remain important, but they should not determine how quickly the institution can respond to a changing business or regulatory requirement.
The real outcome of modernisation
Financial institutions are right to approach structural technology change cautiously. Reliability, security and regulatory compliance leave little room for careless experimentation. But maintaining existing dependencies is not a risk-free decision. It progressively limits how quickly the institution can respond to new regulations, changing fraud patterns and emerging customer needs.
Modernisation should therefore be judged by the freedom it creates after implementation. Can the institution introduce a new rule without launching another large programme? Can it change an operational process without multiplying manual work? Can it replace an underlying platform without disrupting every channel connected to it?
If the answer remains no, the technology may be newer, but the institution is not substantially more modern.
Digital transformation changed how financial institutions interact with customers. Engineering-led modernisation must now change how confidently they can evolve. That achievement may be less visible, but it is a far stronger foundation for resilience.
Authored by Gautam Rege,Co-Founder and Director, Josh Software