Kaleshwar Aryasomayajula of Charles Schwab Outlines a Blueprint for India's Banking Infrastructure Transition

A Senior Software Developer at Charles Schwab explains the demands of India's banking modernization and why replacing legacy systems entirely doesn't work.

From January 2026, India's banks face a new regulatory test. The RBI's Digital Banking Channels Authorisation Directions require banks to demonstrate infrastructure resilience, readiness and cybersecurity certification before they can offer internet and mobile banking services. The pressure comes when India's payments layer is growing fast: in May 2026, UPI processed more than 700 million transactions every day. However, many banks still process the transactions through systems that operate in overnight data cycles, process data in bulk and weren't built to handle today's volume.

For over a decade, Kaleshwar Aryasomayajula has worked on systems of similar complexity and scale. As a Senior Software Developer at Charles Schwab, which is one of the largest financial services firms in the US, he leads engineering for major retirement platform initiatives. His career spans across government, insurance, and large-scale financial services. Over that time, he had to answer the same question: how do you transition infrastructure that must keep running?

When infrastructure doesn't answer the demand, replacing it seems to be an obvious solution. But it means to build the new system alongside the old one, and then switch to it when it is ready. And in financial services that approach involves more risks. A bank clearing millions of transactions daily cannot allow downtime during a migration process. The RBI's new framework sets the stakes: to get authorisation renewed, banks need to demonstrate service continuity. Planning modernization of paper isn't enough anymore.

"The banks that frame modernization as a replacement project suffer the most," explains Aryasomayajula. "In fact, you are transitioning instead of replacing it. Those are architecturally different problems, so they require completely different answers."

Aryasomayajula's methodology has a specific structure. First, the existing system is divided into its logical domains, such as payments, compliance, notifications, risk. Then each of them is ranked by two factors: how much load it carries and how much it would benefit from modernisation. The work starts with domains that involve lower risk. Then for each domain he defines what he calls a safety envelope. It defines an uptime threshold the domain must maintain throughout the transition. It also sets the data integrity standards and describes the rollback strategy for the case something goes wrong. These conditions are determined before the migration even begins.

The transition itself adds a new event layer. It's a software that replaces a scheduled overnight run and routes data between systems when transactions are processed. New services subscribe to events and gradually switch on to fulfill specific functions, while the legacy system continues running. Batch jobs are replaced by streaming processors one at a time. As a result, the business sees improvement throughout the modernisation and doesn't need to wait for a final release date for that. Reliability and security controls are built into each stage as requirements, not added after deployment.

In Aryasomayajula's approach, automated security checks become an integral part of the development. They function as blocking criteria. This means a deployment that triggers a critical vulnerability flag doesn't reach production. This directly corresponds the cybersecurity certification standard the RBI now requires banks to demonstrate.

"Every successful migration I've led was based on the same principles. We define what 'unacceptable' looks like before we start, and then follow this definition," he explains. "On the Maryland work, this meant working with 2.5 million records without losing data integrity. At Schwab, it meant the downtime shouldn't exceed a strictly defined threshold. And when the projects go badly, it often happens because they define failure only after it happens."

The effects of the approach are reflected in numbers. At Charles Schwab, applying the principles described above to the retirement platform's core infrastructure helped to achieve 99.95% uptime. It also lowered times under 200 milliseconds. This is the level of reliability required for a system like a platform that processes more than 150,000 daily transactions in real time. The decision to introduce event-driven processing incrementally also removed issues with manual reconciliation that were typical for batch systems, which brought approximately $2.4 million in annual savings.

The RBI's 2026 framework is asking Indian banks to navigate the same transition that US financial institutions had been working through for the last decade.They need to move from batch-era infrastructure to event-driven systems built for the volumes that digital payments now demand. The institutions that succeed in it don't necessarily need larger modernisation budgets. The key to success is treating the modernisation as an incremental engineering problem with defined standards in each step, not as a single replacement project.