Digital Speed Without Control Is Unacceptable in Banking” — Aditya Agarwal’s View

But the most important announcement was not in the financial numbers. It was about AI. Citi’s AI tools have been used over 21 million times by staff across 84 countries. Adoption rates exceeded 70%, no longer a pilot program. But AI has become a core part of how the bank operates every day.

At the center of this transformation is Aditya Agarwal, Digital Tech Program Lead Analyst at Citibank in Irving, Texas, who sits between engineering ambition and regulatory reality. He connects product vision with technical execution. Over 11 years at Citibank, he has led programs that define what modern banking infrastructure looks like. Among them: a next-generation architecture migration serving approximately 10 million customers, the CitiPay retail payment platform spanning 30 or more merchant partners, and an AI chatbot ecosystem now handling over 12 million customer interactions every month.

Aditya’s work extends past Citi as well. In February 2026, he served on the Expert Board of the AITEX Summit Winter 2026, a two-day online AI innovation event run by the California-registered Association of Information Technology Experts. He evaluated participant projects across product, operational, business, and open analytics categories, weighing each for enterprise viability, regulatory resilience, and practical scalability. The board drew specialists in AI, data analytics, and digital transformation from technology companies, startups, and research institutions, with members chosen for demonstrated impact on the field and recognized standing in the IT community. 

We spoke with Aditya to understand what technical program management really means at scale. His work shows why disciplined execution may be banking’s most underrated competitive advantage.

Aditya, you’ve said that digital speed without control is unacceptable in banking. But you’ve also delivered a 20 to 30% improvement in time-to-market at CitiPay. How do you hold both of those things at once inside an institution operating across 90+ markets?

The first thing you have to do is respect the complexity before you try to change anything. Most transformation efforts fail because people underestimate the interconnectedness of everything. You change one system, and three other systems break. You move one team faster, and a compliance requirement pulls you back.

What actually works is treating transformation as a program, not a project. Projects have a start and an end. Programs have an ecosystem, stakeholders, dependencies, risks, governance, and continuous adaptation. My job is to hold that ecosystem together while pushing it forward.

And at Citi specifically, you’re always operating in two worlds at once: the world regulators expect and the world customers demand. Those two worlds don’t move at the same speed. As I always say, digital speed without control is unacceptable in banking. The TPM’s job is to make sure innovation doesn’t outrun control, and control doesn’t strangle innovation. That tension never goes away. You just learn to work inside it.

You led the Next Gen Architecture migration from 2018 to 2020, serving approximately 10 million retail and card customers, with a 15 to 25% reduction in call center inquiries. That’s the kind of project where one wrong move affects real people’s ability to see their bank balance. How do you manage that level of risk?

You sequence everything. That’s the honest answer. The biggest mistake I see in legacy modernization is the temptation to do a big bang, rip everything out, put the new system in, and move on. In banking, that approach doesn’t just create technical problems.

What we did was build modern layers alongside the legacy infrastructure. APIs, caching, data services, all running in parallel, all validated against the old systems before a single customer touched the new experience. The transition was invisible. And that’s exactly what you’re aiming for. When a customer logs in and everything just works better, faster, cleaner, and more accurately, they shouldn’t have any idea that the entire architecture underneath changed. That’s the win.

When people can find their balance, their transaction history, and their dispute status on their own, in real time, they stop calling. Because they don’t need to anymore, that’s not just an efficiency metric. That’s trust. And in banking, trust is the whole game.

CitiPay meant coordinating 30 or more retail partners, each with their own systems, timelines, and expectations. At some point, that stops being a program management problem and starts being a diplomacy problem. Where’s the line, and how do you hold it?

This is where program management either earns its value or exposes itself. Because the temptation with a program like CitiPay is to treat every partner as its own custom engagement. Home Depot wants this, Macy’s wants that, Best Buy has a completely different stack. If you chase every variation, you never finish building; you’re just constantly rebuilding.

The answer is standardized frameworks with room for flexible execution inside them. You give every partner a clear integration path. You define the technical requirements upfront, not halfway through. You manage vendor deliverables through consistent governance, so nothing surprises you. And critically, you build your escalation paths and rollback procedures before you need them. Because you will need them.

Here’s the thing about a retail payment product: reliability isn’t a technical metric. It’s a revenue metric. If a customer can’t complete a purchase with their store card on a Saturday in December, that’s not a bug report. That’s lost business for the partner and a damaged relationship for Citi. That’s why reliability has to be designed into governance from day one, not bolted on after you’re already in production.

The OCC and the Federal Reserve issue mandates in regulatory language. Your engineers work in technical language. Someone has to stand in the middle and make those two things mean the same thing. What does that actually look like in practice?

A regulatory mandate might say: Establish adequate controls over critical data elements. That sentence means nothing to an engineer. My job was to turn it into something like: Build a data lineage tracker that logs every transformation from source to report, with audit checkpoints at each stage, testable against these specific criteria. Same requirement. Completely different language.

And you have to do that for every mandate, across every workstream, without losing the regulatory intent in the translation. Because if your technical solution doesn’t satisfy what the regulator actually meant, you find out during the next examination, not during development. By then, you’ve already built the wrong thing.

That’s why we built the governance infrastructure first, before touching any remediation. Dashboards, documentation, and audit trails. Not as reporting tools, but as proof of intent. With regulators, transparency isn’t a reporting function. It’s the strategy. Every single decision needs a paper trail. Every deadline has someone external watching who genuinely doesn’t care about your internal constraints. They want to see exactly how you got there, and they want to see it in their language, mapped back to the mandate, traceable from requirement to implementation to validation.

Every bank has made an AI announcement. Most of them sound identical: faster service and better customer experience. But you’re sitting on 12 million customer interactions a month and $250 million in annual cost avoidance. That’s not an announcement anymore. That’s the result. So what are most banks actually getting wrong?

Because most of them are still at the announcement stage. They’ve deployed a chat window. They’ve published the press release. And they’ve moved on. What they haven’t done is ask whether the underlying workflow was worth automating in the first place.

If a customer has a bad experience in a traditional service model, the call goes into a queue. It becomes a trend, someone writes a report, and by the time anyone acts on it, thousands of people have already had that same bad experience. Putting a chatbot in front of that process doesn’t fix it. It just gives the broken workflow a friendlier face.

The 85% first-contact resolution rate we’ve achieved is not a chatbot statistic. That reflects actual integration across systems, teams, and workflows. And the 30% increase in agent productivity isn’t because we cut headcount. It’s because the humans in that system are now doing the work only humans should be doing: fraud cases, complex disputes, sensitive financial conversations that require judgment and empathy. The AI handles volume. The humans handle nuance. When those two things are correctly calibrated, you get sustainable results. Most AI transformations never get to that calibration. They stop at the announcement.

Governing AI delivery, sequencing legacy modernization, and aligning global teams under regulatory pressure are Citibank-specific hardships. Where does institutional impact end and industry-level influence begin?

The methodologies I’ve developed aren’t Citibank-specific. How do you structure governance for AI delivery? How do you modernize legacy systems without disrupting customers? How do you align global teams under regulatory pressure? These are universal hardships. I’ve built frameworks that work across all of them. 

That’s the moment institutional impact becomes insufficient: when you realize the frameworks you’ve built would solve problems beyond the walls you built them in. My longer-term goal is an exciting one for me; I want to formalize these methodologies in ways the broader industry can genuinely learn from.