Building AI for Indian Financial Services: What I've Learned

It’s been roughly a year since I started building AI systems full-time for financial services. Before that, I spent over a decade on the other side - as a researcher at NABARD, as part of a marketplace startup, and as a Priority Banking RM at Axis Bank. This post is an honest retrospective: what I built, what worked, what didn’t, and what I’ve learned about the intersection of AI and Indian finance.

I’m writing this partly for my own clarity, and partly because I think the practitioner’s perspective is underrepresented. Most writing about AI in finance comes from either the research side (papers and benchmarks) or the vendor side (product announcements). The view from someone who has sat across the table from an HNI client and also debugged a production embedding pipeline at 2 AM - I think that’s different enough to be worth sharing.

Lesson 1: Domain Expertise Is the Moat

This is the most important thing I’ve learned, and it’s counterintuitive if you come from a pure technology background.

The models aren’t the hard part. Transformer architectures, graph neural networks, embedding techniques - well-documented, well-tooled, increasingly commoditized. The hard part is knowing what to model, how to frame the problem, and what the output needs to look like for a financial services professional to actually use it.

When I built an LLM-driven campaign segmentation engine, the technical stuff - fine-tuning, prompt engineering, retrieval pipelines - was straightforward. What made it work was knowing that a Priority Banking RM doesn’t want a “segment label.” They want a sentence that explains why this client should receive this offer right now, framed in language they can use in a client conversation. That insight didn’t come from an ML textbook. It came from years of being that RM, sitting across the desk, trying to figure out what to say.

When I built a GNN-based context management system, the graph architecture decisions - node types, edge definitions, attention mechanisms - were shaped by how financial relationships actually work. A client isn’t an isolated node. They’re embedded in a network of family members (HUF structures, joint holdings), financial products (cross-holdings, linked accounts), market exposures (sector concentrations, currency risks), and life events (education timelines, retirement horizons). I knew what edges to model because I’d navigated those relationships manually for years.

As I wrote in my earlier post on GNNs, the graph structure is the insight. But choosing the right graph structure requires knowing the domain.

Lesson 2: India-Specific Data Challenges Are Features, Not Bugs

I wrote about this in detail in my post on India’s AI advantage, but it’s worth revisiting in a retrospective.

Indian financial data is messy, seasonal, multilingual, and structurally different from what most ML frameworks are designed for. When I started, I saw this as a problem to overcome. Now I see it as an advantage to build on.

Seasonality is signal. Festival spending cycles, monsoon-linked agricultural behavior, tax-season investment patterns - these aren’t noise to smooth out. They’re predictive features that Indian-market models should explicitly encode. My drift detection work led me to build season-aware monitoring that treats cyclical patterns as expected variation rather than anomalies. And when you build that same seasonal awareness into the models themselves, predictions get noticeably better.

Language diversity is a feature. India has 22 scheduled languages and hundreds of dialects. Customer communication data - call transcripts, chat logs, complaint texts - is multilingual, code-switched, and full of domain-specific jargon. (What even is a “surrender value” in Tamil banking parlance?) Building NLP systems that handle this is harder than building for English-only markets. But once you’ve built it, the system understands customers that monolingual models can’t reach.

The informal economy creates unique modeling opportunities. A huge chunk of India’s economy operates semi-formally. GST data, UPI transaction patterns, digital footprints - these are creating a data layer that didn’t exist five years ago. Models that can synthesize formal credit bureau data with these alternative signals can serve customers who were previously invisible to the financial system. That’s a financial inclusion opportunity as much as a business one.

Lesson 3: The Three Systems - Architecture and Interconnections

Over the past year, I built three production systems. They started as independent projects but evolved to share a common foundation. Here’s how they connect:

graph TB
    subgraph Foundation["Common Foundation"]
        F1[Financial Domain Knowledge]
        F2[India Market Context Layer]
        F3[Regulatory Compliance Engine]
        F1 --- F2 --- F3
    end

    subgraph S1["System 1: LLM Campaign Engine"]
        A1[Customer Data Ingestion]
        A2[LLM Segmentation & Reasoning]
        A3[Personalized Offer Generation]
        A4[RM-Ready Talking Points]
        A1 --> A2 --> A3 --> A4
    end

    subgraph S2["System 2: GNN Context Manager"]
        B1[Relationship Graph Construction]
        B2[Multi-hop Attention Network]
        B3[Context Vector Generation]
        B4[Real-time Context Updates]
        B1 --> B2 --> B3 --> B4
    end

    subgraph S3["System 3: Embeddings Portfolio Engine"]
        C1[Market Signal Encoding]
        C2[Portfolio State Embeddings]
        C3[Goal-Progress Optimization]
        C4[Allocation Recommendations]
        C1 --> C2 --> C3 --> C4
    end

    Foundation --> S1
    Foundation --> S2
    Foundation --> S3

    B3 -->|Context vectors feed| A2
    B3 -->|Client context informs| C3
    C2 -->|Portfolio state enriches| B1
    A2 -->|Segment signals feed| C3

    style Foundation fill:#37474F,color:#fff
    style S1 fill:#1565C0,color:#fff
    style S2 fill:#2E7D32,color:#fff
    style S3 fill:#6A1B9A,color:#fff

System 1: LLM Campaign Segmentation Engine. Takes customer data - transaction history, product holdings, demographics, interaction history - and uses an LLM to generate natural-language segment descriptions and personalized campaign recommendations. The key insight isn’t the LLM itself but the prompt architecture: structured retrieval of customer context (from System 2) combined with product knowledge and regulatory constraints. I wrote about the technical foundations in my post on LLMs in banking.

System 2: GNN Context Manager. Maintains a dynamic graph of client relationships, product holdings, and market exposures. Each node has a learned embedding, and the graph attention network generates context vectors that capture a client’s position in a broader financial network, not just their direct attributes. When a market event occurs - say, an RBI rate decision - the system propagates the impact through the graph to figure out which clients are affected, through which channels, and how urgently. I discussed the architecture in my post on graph neural networks.

System 3: Embeddings-Based Portfolio Allocation Engine. Encodes portfolio states, market conditions, and client goals as dense vectors in a shared embedding space. Portfolio optimization becomes a nearest-neighbor problem: given the current portfolio state and goal trajectory, what’s the nearest achievable allocation that maximizes goal-progress probability? The embedding approach handles dimensionality that traditional optimization chokes on - 15 goals across a joint family, 200+ available instruments, real-time market signals. Explicit optimization is intractable at that scale. Embeddings make it tractable. I explored the underlying concepts in my earlier post on digital wealth management.

The interconnections are where things get interesting. GNN context vectors feed into the LLM campaign engine, giving it richer client context than raw data alone. Portfolio state embeddings enrich the relationship graph, so the GNN knows not just that two clients are related but how their portfolios interact. Campaign segment signals feed into portfolio optimization - if the system identifies a client in a “retirement planning intensification” phase, the portfolio engine adjusts goal weightings accordingly.

Each component works independently. But the shared foundation - financial domain knowledge encoded as features, India market context as a contextual layer, regulatory compliance as a constraint - that’s what makes the whole thing more than the sum of its parts.

Lesson 4: What I Would Do Differently

This is the section I’ve thought about the most.

I would invest in data infrastructure earlier. I spent the first three months building models and the next three months rebuilding the data pipelines that fed them. In retrospect, I should have spent the first two months on data infrastructure - feature stores, data validation, pipeline monitoring - and then built models on a solid foundation. Every ML practitioner knows this in theory. I learned it by wasting time.

I would build evaluation frameworks before building models. How do you know your campaign segmentation is good? I had intuitive benchmarks from my RM experience, but I didn’t formalize evaluation metrics early enough. By the time I had rigorous offline evaluation in place, I’d already made architectural decisions that were hard to reverse. The right sequence: define what “good” looks like, build the evaluation harness, then build the model.

I would talk to more RMs during development. I had the advantage of having been an RM myself, but my experience was at one bank, in one geography, with one client segment. I should have set up regular feedback sessions with active RMs across different banks and segments from day one. The insights from those conversations - which I eventually had - changed my feature engineering significantly. Some of the things they told me were embarrassingly obvious in hindsight.

I would be more aggressive about simplicity. My first iteration of the GNN context manager was overengineered. Six node types, fourteen edge types, three attention heads. The version that actually works well in production? Three node types, five edge types, two attention heads. In financial services ML, the simpler model that you understand deeply almost always beats the complex one you understand partially. Especially when you need to explain decisions to a model risk committee.

Lesson 5: What Is Next for AI in Indian Financial Services

Looking forward, I see three big opportunities.

AI-native credit underwriting for the underserved. India has approximately 200 million adults with thin credit files - enough income to qualify for financial products but not enough formal credit history for traditional underwriting. Alternative data (UPI transaction patterns, GST filing behavior, digital footprint signals) combined with ML models that can learn from sparse, noisy data - that’s a massive opportunity. RBI’s digital lending guidelines create a clear regulatory framework. The technical challenges are real (sparse data, class imbalance, fairness constraints) but solvable.

Unified financial planning across products and regulators. Right now, banking products (RBI-regulated), investment products (SEBI-regulated), and insurance products (IRDAI-regulated) sit in separate technological and advisory silos. But the client’s financial life doesn’t respect regulatory boundaries. An AI system that can reason across all three - optimizing the interplay between loan prepayment, investment allocation, and risk coverage - is what the market actually needs. Building this takes deep understanding of how all three regulatory frameworks interact, which is where practitioners with cross-domain experience have an edge.

Real-time, personalized financial wellness. Not robo-advisory as it exists today, but genuine AI-driven financial coaching that understands the client’s complete context. “Your EMI-to-income ratio will breach 50% if you take this car loan - here’s an alternative structure that keeps you at 42%.” Or: “Based on your spending pattern, you can increase your SIP by INR 5,000 without affecting your liquidity cushion.” This requires the kind of continuous, context-aware reasoning that the three systems I built are designed to enable.

The Practitioner’s Edge

If there’s one thread running through everything I’ve learned, it’s this: in financial services AI, the practitioner who has lived on both sides - the banking floor and the ML pipeline - has an edge that’s hard to replicate.

Not because the technology is inaccessible. The tools are open-source, the papers are public, compute is affordable. The edge comes from knowing what questions to ask. Knowing that an Indian HNI’s financial life is a family affair, not an individual one. Knowing that October data looks different from June data for reasons that have nothing to do with model quality. Knowing that an RM needs a talking point, not a probability score.

Models improve every year. Data infrastructure gets better. Compute gets cheaper. But the ability to translate between the language of finance and the language of machine learning - knowing what to build, not just how to build it - that comes from years of accumulated context. No foundation model can replicate that, at least not yet.

I started this journey with a hypothesis: someone who has spent a decade in Indian financial services, who understands the clients, the products, the regulations, and the cultural context, can build AI systems that are fundamentally better than what a pure technologist would build. A year in, I’m more convinced of that than when I started.

India has 1.4 billion people and a financial system digitizing faster than any other large economy. The AI systems that will serve this market need to be built by people who understand India, not just people who understand AI.

For anyone considering a similar path - from financial services practitioner to AI builder - your domain expertise isn’t a stepping stone to a technology career. It’s the foundation of one.