Banks must get their data strategy right for AI: Maverick Systems CTO

Banks are trying to bring generative AI and agentic AI into core operations without breaking controls that are built for low error tolerance. In a conversation with TechCircle, Kishan Sundar, Senior Vice President and Chief Technology Officer at Maverick Systems, described what he sees banks getting wrong as they modernize for AI, and what “trust” looks like in practice. He also outlined how his team is approaching data lineage, drift monitoring, and a set of internal platforms focused on operations, testing, and software delivery in regulated environments.

Edited Excerpts: 

In banking, where there’s “zero scope of error,” what makes a core banking environment AI-ready without replacing everything? What do banks usually get wrong?

I see three main capabilities that determine whether core banking is ready for AI, and banks often struggle because they underestimate the work behind them.

First is data. Banks were among the earliest adopters of technology, so many are sitting on legacy stacks that are two or three decades old. Because of that, data is scattered across systems, the same data may live in multiple places, and there may be no single source of truth. The efficiency and the relevance of what AI produces, its inference, its reasoning, and the explainability for why it produced an output, depend on the data you feed it. So the biggest challenge is getting the data strategy right, and the biggest hurdle has been fragmentation. What is changing is that banks can now use AI to help build their data catalog, master data management (MDM), and lineage, not only from a data perspective, but also from an application and functionality perspective, because completeness and effectiveness for AI depend on that.

Second is the reality that core systems have accumulated a lot of changes over time, some recorded, some not. That holds banks back in modernization and transformation. With AI, we can uncover business rules, changes, and configuration settings inside applications to generate a live requirements or functionality document of what the application is actually doing. With a clean, live document, banks can assess the impact and risk of new changes, and they can be clearer on what the target state is during upgrades, including what needs to be tested to keep the transformation clean. That also simplifies the landscape. If a process used to have six handoffs between systems, simplification can reduce that, sometimes to half the handoffs, which makes process automation easier.

Third is productivity across technology and operations teams. A lot of repetitive work can be mitigated by bringing in AI and, in particular, agentic AI. I emphasize agentic AI because you can mimic an agent as a developer to do repetitive developer tasks or as a tester to do repetitive testing tasks. You can also build multiple agents that reflect how operations work—for example, an L1 AML operator as an agent—with guardrails so it behaves like an L1 operator and doesn’t go beyond that, and then apply the same approach for L2 and L3. With agentic AI and human-in-the-loop, repetitive bank activities are getting touched.

When you talk about building trust in AI-enforced banking systems, what’s the measurable definition? Is it fewer fraud losses or faster dispute resolution?

Trust starts with explainability: clear source citation and traceability so humans can see the decision, reasoning, and inference behind an output. At least this year, I don’t see banks moving to fully autonomous AI; it will remain human-in-the-loop, and that transparency is what lets people act faster.

The next layer is a trusted enterprise knowledge source. For the work we’re doing, we’re building a “knowledge lake” by collecting the documents teams use every day, creating a knowledge graph around them, and tagging and classifying content so questions can be answered with relevant, retrievable information.

Third, governance and guardrails are non-negotiable in BFSI. On the policy side, that means ethical AI guidelines aligned to standards like NIST or ISO, clear usage boundaries, and risk classification for use cases. On the technical side, it includes hallucination detection, toxicity filtering, and enforcing RBAC (role-based access control) so restricted document sections stay restricted, even for AI agents. You also need escalation workflows and incident playbooks that fit with existing operations, simplifying without breaking established procedures.

Even with all of that, model risk management is often the biggest blocker. Banks need MRM sign-off that the model has been validated end-to-end, drift is monitored with defined alert thresholds, and bias and fairness testing are documented, plus an independent model review. In practice, that process slows adoption more than the guardrails themselves.

I’m leaving customer transparency aside here because this is about what holds adoption back inside the bank. After those hurdles, the question becomes how to protect customer trust. For example, with “agent assist,” AI guides a human agent on what the customer needs and the next best action, without putting AI directly in front of the customer. But when a bot manages the interaction, disclosure becomes the key question: how do you make that clear?

As AI becomes integral to core banking, what level of data lineage is practically achievable, and how do you handle lineage across third-party data, SaaS services, and legacy systems?

Historically, lineage in banks was often only at the data store level. Many banks have matured to establish lineage at the store, where data came from and how it was stored, so you can traverse that path, even if the data itself is fragmented across applications.

Now, with AI, we are pushing into two additional areas. One is lineage, when data is in motion, what transformations it goes through as it moves. We are working with certain banks to establish that. The second is dealing with the shift toward SaaS embedded in banking journeys. Earlier, many applications were self-hosted. Now SaaS services are getting embedded; onboarding is a good example, where activities can occur through systems like sales or lifecycle management tools. Establishing lineage, what goes in and what comes out, becomes trickier in that environment.

That is where we are building a solution around data governance, bringing what I referred to as “GNI” into establishing lineage. In the end, lineage information may sit in tools like Solidatus or Collibra, but our accelerators enabled by GNI traverse the path from a metadata catalog, including motion, internal systems, and external systems.

We’re also dealing with another complexity: earlier lineage work often assumed RDBMS (relational databases) or systems that follow industry standards, but some core banking systems store data in their own formats. For example, Terminus uses Oracle but stores data in its own structured way. With AI, we can understand how the catalog is stored and what documents it creates, and map to that.

In terms of timeline, we are aiming that after a couple of iterations—by mid of the financial year, by Q2 of FY26-27—we should be able to say we have rolled it out in a couple of banks and we are successful in that.

Banking environments drift constantly. What’s your approach to detecting model drift and performance degradation without creating noise, and what’s the escalation path when drift is detected?

Our DNA for the last 25 years has been testing, and we’re applying that now in two ways: using AI for testing, and also testing AI efficiently and effectively.

We see model drift mainly from patterns evolving, new regulatory asks, and, when applied against customers, changes in customer behavior. All three show up through changes in input data distribution. When the input distribution shifts, you can see data drift, concept drift, or prediction drift.

We’re measuring impact in a few ways right now. One is usage feedback, whether the user says the reasoning was accurate. Another is whether the error rate increases. And for generative AI specifically, we look at hallucination-related signals, such as how our guardrails block prompts from being answered, whether we require follow-up prompts, and how many multi-level prompts are being made to get an answer.

Until now, backtesting was the core method, but we are moving away from relying only on backtesting. We are working toward continuous review rather than only periodic review of responses and acceptance.

Over the next 12 to 18 months, where is Maverick Systems investing most, in technology and non-technology areas like governance, audit tooling, data lineage, or model ops?

We are working on five platforms with AI at the heart of them, and they touch the areas you mentioned.

One is what we call Prism. Prism is about understanding the operational flow of banking activities. We map user journeys so operations teams can view what is happening at any point: what data went into an activity, why it failed, and whether a passed activity is adhering to regulation. It can go to granular levels for review and audit. We are currently doing this for KYC, KYB, and AML—covering the lifecycle from onboarding through periodic KYC, including cases like change of address. Operations teams used to struggle and, in some cases, take two to three days to complete the lifecycle. With this platform, we believe it can be expedited and, worst case, completed within a quarter of a day for every case.

The second is what we call Pulse. Pulse is intended to show the quality of the banking technology stack and how generative AI can be used to verify and validate not only technology tasks but also functional behavior—whether it’s working as expected and behaving the way it was conceptualized. We are trying to automate testing by bringing in generative AI while keeping testers, test managers, and test architects in the loop. That spans requirement engineering for completeness, visualizing test strategy, creating test design, and converting that into test scripts that can run in tools like Selenium or, for APIs, the Karate framework—then scheduling and multi-threading execution rather than running sequentially. We have built this and are trialling it with a couple of banks.

The third area is related to what I called “Vibe development,” which I said has limitations in banking. Banks want traceability: why code was built, for what change, whether it was reviewed, and how it got integrated. Also, this approach works better in greenfield environments, while many banking programs are brownfield projects. So we are building our own AI-native SDLC (software development lifecycle) that still follows engineering methodology—reviewing a user story, breaking it into tasks, developing code, checking in, testing, refactoring, and moving to the next task—but the workflow happens through prompts, with developers in the loop to validate accuracy and refactor for design.

We are using it internally for our applications, and we are seeing a 40% reduction in the development lifecycle—from requirement elaboration through code merge.