.png){kind=logo}
More than four in five financial institutions now deploy artificial intelligence at some level. That figure comes from the 2026 Global AI in Financial Services Report, published in April by the Cambridge Centre for Alternative Finance and drawn from more than 600 institutions across 151 jurisdictions. It reads like a success story. The same report tells a second one: only 40% of those institutions have reached advanced adoption, and established players remain stuck disproportionately at the pilot stage. The researchers traced the gap not to the quality of the algorithms but to the infrastructure beneath them. Among the AI vendors surveyed, 72% named data quality and completeness as their most acute challenge with financial clients, and 46% pointed to legacy systems and siloed environments.
Kaleshwar Aryasomayajula has spent more than a decade on precisely that layer. A Senior Software Developer at Charles Schwab, a leading US brokerage and financial services firm, where he leads engineering on major retirement-platform initiatives, he has built event-driven architectures, DevSecOps pipelines and real-time data systems, first in government and insurance, later in financial services. His read on the industry's AI problem is blunt: firms are buying models that their systems cannot run in production.
An AI decision in fraud detection, credit scoring or risk monitoring assumes the data feeding it is accurate and current. At many established institutions, it is neither. Batch processing remains the norm: data is gathered and run in bulk on fixed cycles, often overnight. That is adequate for reports and end-of-day reconciliation; it is useless to a model deciding in real time. A model trained on clean data and then fed stale data produces unreliable output. In a payment or retirement system clearing hundreds of thousands of transactions a day, data accuracy stops being a performance metric and becomes a question of whether the platform can be trusted at all.
At Charles Schwab, Aryasomayajula led the move from legacy batch processing to event-driven microservices, and the resulting numbers were a direct consequence of the call and proof that the approach was the right one: data accuracy rose from 94% to 99.7%. Response times fell below 200 milliseconds across more than 150,000 daily transactions, and the platform held 99.95% uptime, with failsafes and caching built to stop a single bottleneck from cascading into an outage. The rebuild also removed the manual reconciliation that batch systems generate, saving roughly $2.4 million a year. That last figure was a by-product; the case for the work had been made on performance alone.
“The hard part is never the migration itself,” Aryasomayajula says. “It's walking into a room and telling people that a system which has run fine for ten years is quietly putting a ceiling on everything they want to do next. Nothing is on fire, and that is exactly why it's a hard sell. The cost of batch processing doesn't show up until the day you try to scale on top of it. By then, you've already built on the crack.”
The same report put data privacy and protection at the top of its risk list, cited by 74% of industry respondents. Behind that number sits a familiar engineering failure: security bolted on as an audit layer after deployment instead of being designed in from the start. An AI system is only as secure as the pipeline feeding it, and governance added after the fact does not change that.
For more than a decade, Aryasomayajula has treated security as a measurable engineering property, ranked alongside performance and uptime rather than parked in a compliance checklist. At the Maryland Insurance Administration, he built the Enterprise Complaint Tracking System, holding personal data for over two million residents and serving more than 50,000 external users; two-factor authentication, end-to-end encryption and automated address validation went into the architecture itself, and the system met 100% of state security requirements.
At Charles Schwab, the same principle ran at a different scale. He wired automated security scanning into the CI/CD pipeline as a blocking gate, not an advisory note: any build that raised a critical-vulnerability flag did not ship. Critical vulnerabilities across systems handling high-value financial data fell by 87%.
“Teams love the idea of a security review at the end,” he says. “It feels responsible. But a review at the end only tells you what is already broken. It cannot make the system safe, because the unsafe choices were made months earlier, in the architecture. By the time a model is reading from that pipeline, you are not securing a system anymore. You are negotiating with one.”
Models in production do not stay still. They need retraining and redeployment as markets move, regulations change, and data drifts. Where release cycles are long, updating a model is not routine maintenance but a scheduled production event. The longer it takes to ship, the further the live model drifts from the market it is meant to track.
Aryasomayajula's response has been to treat deployment itself as an engineering discipline with measurable standards. On a Maryland state transportation platform, that meant moving to CI/CD through Azure DevOps, cutting release cycles from two days to four hours and putting updates on a predictable two-week cadence.
“If you ship twice a year, every release becomes an event people dread, and dread makes them cautious in all the wrong ways,” he says. “They batch up changes, and big batches are exactly what breaks. Ship every two weeks, and deployment turns boring. Boring is the goal. A model retrained on a boring, predictable pipeline is one you can trust in production, because nothing dramatic has to happen for it to stay current.”
None of Aryasomayajula's work at Charles Schwab or Maryland's agencies began with AI. Across a decade and several organisations, the sequence held: fix the data pipeline, make security a measurable standard, turn deployment into routine, and a platform that can run AI reliably follows. Most institutions, the Cambridge data suggests, are still near the start of that sequence.
Better models will not close that gap. The work that closes it is the engineering layer that AI budgets tend to skip. The institutions that get AI right in production will not be the ones with the cleverest models. They will be the ones who did the work underneath them first.
