Modern banking demands speed and agility, but legacy core systems continue to underpin critical operations. The focus is now shifting towards smarter architectures that enable innovation without disrupting the core. Gautam Rege, Co-Founder and Director, Josh Software, shares his perspective on decoupling innovation from legacy systems, leveraging APIs and modular architectures, and preparing banks for AI-led transformation in an interaction with Vishwas Sinha of Elets News Network (ENN). Edited Excerpts:
Q. Core banking platforms are built for stability but can sometimes limit the speed of digital innovation. What are the biggest challenges banks face today when trying to innovate around legacy core systems?
The biggest constraint is not necessarily the core system’s age. It is how much business logic has become embedded within it, and how many applications, processes and vendor dependencies have accumulated around it.
A seemingly simple change to a transaction limit or onboarding journey may cut across the core platform, channel applications, KYC and fraud systems, customer classifications, approval workflows and several internal teams. The exact systems involved will depend on where the relevant business rules reside. When these components are tightly coupled, even a contained change can trigger multiple dependencies. Development takes longer, regression testing expands, and deployment may have to align with vendor release schedules and tightly controlled change windows to avoid disrupting critical banking operations.
Technical debt compounds this problem. Over time, temporary integrations, duplicated workflows, and manual reconciliations become part of the operating model. Banks may modernise the customer interface, but the work behind that interface continues to move through fragmented systems.
The challenge, therefore, is not choosing between innovation and stability. Banks need both. The real task is to isolate change so that a new customer journey or business rule does not require invasive changes across the technology estate. Modernisation becomes meaningful when a bank can introduce change quickly without compromising the stability of its core systems.
Q. How can banks introduce new digital products, customer journeys and channels without making disruptive changes to their core banking infrastructure?
Banks can treat the core as the system of record without requiring it to become the system through which every new experience is designed.
A practical approach is to build an innovation layer between the core and customer-facing channels. This layer can contain the APIs, business rules, workflow orchestration and channel-specific services needed to create new products and journeys. The core continues to manage accounts, balances and transactions, while the surrounding layer determines how these capabilities are presented and used.
Consider digital onboarding. The mobile journey may need identity verification, document checks, eligibility rules, consent management, and exception handling. Instead of embedding the complete journey within the core, these capabilities can be coordinated outside it, with only the required information ultimately written back to the system of record.
This allows teams to redesign one part of the journey, add a new channel or modify a rule without reopening the core for every requirement. It also supports gradual modernisation. Banks can begin with one high-friction capability, prove the architecture and extend it incrementally. The objective is not to bypass the core, but to protect it from carrying responsibilities it was never designed to change frequently.
Q. What role do APIs, microservices and composable architectures play in helping banks decouple innovation from their core systems?
APIs, microservices and composable architectures are useful when they create clear boundaries around change. Their value does not come merely from adopting modern terminology.
APIs provide controlled access to capabilities and data within existing systems. A digital lending application, for example, can retrieve customer information or submit a transaction through a defined interface without needing to understand the internal workings of the core platform.
Microservices can separate capabilities that evolve at different speeds. Identity verification, notifications, eligibility checks and document processing can be developed, scaled and deployed independently when the business case justifies that separation. Composable architecture then allows these capabilities to be assembled into different products and journeys instead of being rebuilt for every channel.
The caution is that poor boundaries can turn a monolith into a distributed monolith, which means more services, but the same dependencies. Banks need to design around business capabilities, data ownership and operational accountability, not simply divide applications into smaller components.
Done well, this architecture reduces the blast radius of change. It is often more practical than replacing the core because it allows banks to modernise the capabilities, creating immediate business constraints while preserving the stability of systems that continue to perform reliably.
Q. How is Josh Software helping banks build an innovation layer around their existing core while continuing to use the core as the system of record?
At Josh Software, we generally begin by identifying where a bank can gain greater control over change. It may be a business rule that takes months to modify, a customer journey spread across several vendor systems or an operations team relying on manual reconciliation to complete a digital process.
The response is not automatically to replace the core or introduce another packaged platform. We work with the bank to engineer a layer around its existing systems using APIs, modular services, configurable business rules and modern operational interfaces. The core continues to maintain the authoritative banking record, while the surrounding layer manages capabilities that must respond more quickly to business, customer and regulatory requirements.
In one engagement, for example, we worked with an established bank to modernise its re-KYC process. Instead of altering the core, a unified digital journey was created for customers completing re-KYC independently and employees assisting them at branches. Prefilled information, OTP and biometric verification, and validation checks were orchestrated around the existing systems, with verified information ultimately recorded in the core. This reduced dependence on fragmented, manual processes while keeping the underlying banking infrastructure stable.
We see such initiatives as co-solved problems. The bank contributes its domain, risk and operational knowledge, while the engineering partner converts that knowledge into adaptable infrastructure that remains under the bank’s control.
Q. With AI, GenAI and real-time banking gaining momentum, how can banks modernise their technology stack while addressing security, compliance, integration and operational risks?
Banks should not rush to add AI to every product simply because the technology is available. The more useful question is where AI can solve a genuine customer or operational problem better than the existing approach.
Customer service, product discovery, document processing, fraud-signal analysis and internal operational support are all promising areas. In conversational banking, for example, AI can allow customers to express what they need in natural language, discover relevant services and navigate complex journeys more intuitively. APIs can connect this conversational layer with existing banking systems, while regulated transactions and authoritative records remain within the bank’s controlled infrastructure.
However, AI cannot compensate for fragmented systems or unreliable data. Banks need governed data, clearly defined access controls and an integration architecture that allows AI applications to interact securely with existing platforms. Controls must also reflect the use case: a system helping customers discover services presents a different risk from one influencing credit, fraud or compliance decisions. Higher-risk applications require explainability, human oversight, continuous monitoring and auditable decision trails.
The same discipline applies to real-time banking. Speed creates value only when fraud checks, consent, compliance and exception handling can operate alongside it. The objective is neither indiscriminate adoption nor excessive caution, but purposeful adoption with proportionate controls.
Q. Looking ahead, do you believe the future of banking modernisation is about replacing the core or building smarter layers around it? What should CIOs and CTOs prioritise over the next few years?
The future of banking modernisation cannot be reduced to a universal choice between replacing the core and building around it. Every institution has different business priorities, operating realities and architectural constraints. Any decision concerning the core must therefore be driven by a clear business need, not treated as the default response to every new digital requirement.
The more important priority for CIOs and CTOs is to avoid exchanging one form of vendor dependence for another. If every new requirement is addressed through an additional packaged product, the bank may gain functionality without gaining control. Business rules remain embedded in closed systems, changes continue to depend on external roadmaps, and the architecture becomes more fragmented over time.
Banks should instead identify where the inability to change is creating a real business constraint and build the necessary APIs, modular services, configurable workflows, and data layers around those gaps. This requires the right internal teams and engineering partners who can build to the institution’s requirements rather than requiring the institution to adapt to a predetermined product.
The bank should remain in control of the rules, priorities and resulting infrastructure, while the partner contributes the engineering capability needed to translate them into adaptable systems. This allows modernisation to proceed incrementally and efficiently, enabling the institution to introduce new products, channels and AI capabilities as genuine needs emerge without waiting for permission to change.
