What Seven Years of Waiting Taught Me About Building AI

It was 2017 and I was in San Francisco to speak at a fraud analytics conference. I had a confirmed slot on the programme, I knew what I was going to say, and I had arrived well in advance. What I hadn’t anticipated was what I would witness in the corridor minutes before I went on to the stage.

Someone was demoing an Enterprise AI platform. Automated machine learning – the full cycle, right from data to deployed model, automated. I stopped. I took out my phone and started looking it up. I got so lost that by the time I looked up again, my session had started without me.

That moment deserves more than a passing mention, because what made me momentarily pause that day wasn’t the technology itself. But it was the familiar recognition of a recurring thought. A thought that kept presenting itself to me as a problem – since 2012 – why aren’t we building a solution framework for the repetitive task of data-to-decision. Precisely five years earlier. And now here it was – built, funded, and being shown to a room full of people while I stood in a corridor watching it on a phone screen.

I want to now express what that recognition of that familiar problem meant that day, and what I did with it – because what led up to that corridor, and what unfolded afterward, all makes it worthwhile to say that it was the start of an AI solution to a real-world problem. 

How the Whole Industry Worked in 2012

At Fiserv, I managed a team doing work that would today be called data science. At the time, the job titles were statistician, data analyst, data engineer – the term data scientist hadn’t come into common use in banking yet. We were building a decision optimization solution for retail banks, and by the standards of the time it was serious, rigorous work.

The way we worked, though, was the way everyone in the industry worked. Every time a new banking client came onboard, the cycle began again from the beginning. Prepare the data. Build the statistical models. Deploy them. And then, because there was no systematic monitoring or performance-tracking framework in place – not at our firm, not anywhere in the industry – managing this whole process manually, month on month. We were not doing anything wrong. We were doing what the tooling and the market allowed.

But when you are inside that cycle long enough, a question starts to form. Not from a critical point of  how things were being done, but arousing from a genuine curiosity about what may be possible if we stepped back from the cycle entirely. We were spending significant time and skill repeating work that, in principle, a well-designed system should only need to do once. What would it mean to automate it end-to-end?

I brought that question to my boss. He was experienced, respected, and careful in the way that good leaders in regulated industries tend to be. He listened to what I was proposing: automating the entire model-building cycle using AI – and then gave me his well-considered response: not yet. The market isn’t ready for this. It will fail.

He was right about the timing, and I want to be clear about that. In 2012, the infrastructure required to make this kind of platform viable simply wasn’t there. The tooling wasn’t there. The market appetite in banking for automated machine learning didn’t yet exist in a form that would support a real product. Being early in deep tech isn’t a virtue – it’s a risk, and a serious one, for everyone involved. His call was sound. I accepted it and moved on.

But the question stayed with me.

A Different City, The Same Problem

A few years later, I joined Zafin, a financial technology company redefining how banks approach pricing and billing. Zafin’s journey would eventually culminate in its acquisition by Nordic Capital, a testament to the caliber of the work being done there. But in those years, what mattered most to me was the problem I had been carrying since my Fiserv days. Working with another firm at the center of global banking only deepened my conviction and revealed new dimensions of the same stubborn challenge.

It was in this context that I was invited to speak at that conference in San Francisco in 2017. Which is how I ended up standing in a corridor, late for my own session, watching a demo of an Enterprise AI platform on my phone.

When I got back, I went to Zafin’s leadership team and made the case for building this capability internally. The response, once again, was to wait. The timing wasn’t right. I understood. By now, I had watched the market arrive at the solution for a problem I had recognized back in 2012. The idea was no longer premature. The infrastructure existed. Someone had already proven it could be built. What I couldn’t do this time was let it slip by again.

So I came back to India and, over the course of about a year, wrote the complete blueprint of the AutoML code myself. Soon, I was joined by my Co-Founders, Amit Kumar and Mohammed Nawas, and they took another six months of grit and relentless hard work to build the entire framework from the ground up.

A Separate Answer to the Same Question

I want to say something carefully here, because it matters.

I never got to see another Enterprise AI platform’s architecture. I never got a chance to examine their code, never got an opportunity to do a systematic comparison of their features, never worked backward from what they had built to find gaps, if any. When I sat down to start writing that code, I wasn’t trying to build a better AutoML platform. Rather I was now building on the disruptive thought that had presented itself to me as a problem in 2012 – and I was determined to find the solution – my own answer, shaped by my own understanding of the problem, formed over the years of working inside the operational reality of banking analytics.

That was a different kind of starting point, and it produced a different kind of end-product. When you build from competitive analysis, you start with what already exists and try to find where the gaps are. You end up building toward a benchmark. 

When you build from years of working inside an operational problem – from understanding how work actually gets done, where the friction lies, what problems practitioners have quietly learned to work around – then you ask a different kind of question: what does the right solution look like from here? 

The first approach tends to produce better features.  The second approach tends to place more importance on foundational architecture – one that is able to withstand regulatory scrutiny and the scale of a global financial institution.

The difference isn’t visible when someone demos the product. It shows up later, when the edge cases arrive.

When institutions like SBI Life, Bank of Maharashtra, Munich Re, and Nippon Life chose iTuring.ai for core systems – not peripheral projects, but core systems – they were making a decision with significant consequences. Banks of that scale, under that level of regulatory scrutiny, do not take that kind of risk on a startup unless they have looked hard at what is under the hood. The fact that they chose us, gave me validation and satisfaction that the decisions on architecture that we made during the hard years had after all been right than any amount of market validation that we could have got.

What Building From the Inside Produces

When I wrote that original code, I was encoding fifteen years of understanding about how banks actually build and manage models – not how they should do it in theory, but how it works in practice, under real conditions, with real regulatory requirements and real operational constraints.

Explainability was built into the platform from the beginning, not because a consultant told me it would be a differentiator, but because I had been in the room when auditors asked questions that most AI systems had no way to answer. Governance was engineered into the foundation – not added later as the EU AI Act began to take shape – because I understood from the inside that a model which cannot account for itself is not a useful asset in a regulated institution, regardless of how accurate it is. The tens of thousands of prebuilt features specific to banking and financial services stemmed from years of watching analysts recreate the same features from scratch across every new engagement, and I knew precisely what they were always going to need.

None of these are selling points that were added to win deals. They are what naturally emerges when a platform is built by someone who has spent a long time on the inside of the problem, rather than studying it from the outside.

I spent a long time watching the industry celebrate speed – fastest to deploy, fastest to scale, fastest to raise. The question I’d leave with anyone evaluating AI is not which platform has the most features, or which has raised the most capital. Eventually, the ultimate goal isn’t innovation for its own sake; it is the resolution of substantive, real-world challenges that persistently present themselves.