Use AI to Innovate in Financial Services

Summary

Financial institutions can build AI that survives a regulator's audit, but only if they can reproduce every past decision exactly and prove why each one happened.

In this DataCamp session on using AI to innovate in financial services, host Richie Cotton talks with Rajesh Iyer, VP of Enterprise AI Transformation at Capgemini, and Maddie Daianu, who leads data science and DataGen.ai at Credit Karma. Both work under strict banking and fintech regulation, and both argue that a working chatbot is the easy part. The hard part sits underneath.

Iyer has built about 180 AI use cases since November 2024, with roughly 10% reaching production. He explains why compliance in banking demands that a system replay a two-year-old decision using the data, model endpoint, and steps from that time, and why most banks are not built to do this. Daianu describes Credit Karma's five-layer system of intelligence, from data through action, and the prelaunch and postlaunch checks that catch hallucinations before they reach 130 million users. They cover why nondeterministic language models are acceptable when they stay semantically deterministic, when to build versus buy, how smaller fine-tuned open-source models cut latency, and which skills separate people who ship AI from people who stall. The conversation runs practical throughout, with concrete examples from underwriting, credit card recommendations, and debt consolidation.

Key Takeaways

• Compliance in banking requires reproducing a decision from years ago using the exact dataset, model endpoint, and intermediate steps from that time, and most institutions cannot do it yet.
• Nondeterministic language models work in regulated settings when their output is semantically deterministic, meaning different wording that carries the same meaning and picks the same choice every time.
• Credit Karma runs a five-layer system of intelligence: data, insights, machine learning, reasoning, and action, wrapped in a product experience.
• A prelaunch check combines de-skewing training data, a larger language model acting as judge, a dynamic tagging system, and humans reviewing a subset of outputs.
• In fintech, 96% accuracy is not enough, because a hallucinated benefit on a credit card summary breaks compliance with what partners require.
• Build the layers that give you a competitive advantage and buy the parts that change fast, such as commercial language models and GPUs.
• Moving from large models to smaller fine-tuned open-source models cut answer latency from around ten seconds and lowered cost.
• The skills that matter most are running evaluations, using AI to learn on demand, and asking a model what can go wrong rather than what will go right.

Deep Dives

The five-layer system of intelligence that powers financial AI

Daianu frames the whole discussion around capability rather than tools, because tools change every week. She describes five layers Credit Karma builds on. First comes the data layer. Then a layer that extracts insights from that data, connecting user profiles, product information, and behavior. Third sits the machine learning or deterministic AI layer, which decides what to show a user in a predictive way. Fourth is a reasoning layer that explains the prediction and interacts with the user. Fifth, the system starts acting on the user's behalf, which she calls the hardest layer to crack. On top of all of it sits the product experience.

She is clear about what she values most in the work. As Daianu put it, "I'm really proud of building intelligent AI systems." The point is that no single layer wins on its own. A chatbot with nothing underneath it fails in a regulated market, and predictive machine learning without a reasoning layer cannot explain itself to a user.

Iyer adds a tooling angle to the same structure. He argues that data and generative AI feed each other in both directions. Companies need good data to run generative AI, and they increasingly need generative AI to prepare the data, because so much of it arrives unstructured across text, images, video, and audio. He points to multimodal embedders that map every modality into the same vector space, then combine that with structured data through an indexing layer. That combined surface becomes the control point for agentic systems. Cotton summarized the shared view: good data at the base, deterministic machine learning and business logic above it, and room to add value at every level rather than betting everything on one agent.

Reproducing decisions: why replay is the bar for banking compliance

Iyer sets a high standard for what production AI in banking must do. As he described it, "what I have to be able to do is actually build solutions that can actually reproduce decisions from the past exactly right." That includes the intermediate steps, not just the final answer. He says he has not seen a single solution across his clients that does this for compliance, only replay built for debugging.

The requirement is specific. To defend a decision from two years ago, a bank needs the dataset from two years ago, the model endpoint from two years ago, the standard operating procedures from that time, and the same intermediate steps leading to the same outcome. Without that, Iyer warns, institutions are setting themselves up for MRAs, the Matters Requiring Attention that regulators issue against banks. He believes many US banks are heading that way given how they build AI today.

The engineering answer is tight telemetry. Iyer says teams must track every point where they send something into the model layer and every response that comes back, end to end, including why the system chose one branch over the others. He warns against convenient shortcuts that hide this trail. As he put it, "you don't really get telemetry for all the different back and forths it does with the LLMs," so those approaches fail an audit. He mentions tools such as Virtue AI that flag which rules apply under a given regime, but he stresses that no tool exempts a team from tracing what goes in and what comes out. Get that visibility, he argues, and you can satisfy almost any regulation.

Semantically deterministic: why probabilistic models are safe enough

An audience member named Roland asked the obvious question. If regulators want the same answer every time, why use probabilistic models at all? Iyer answered with a distinction he cares about. A language model is not literally deterministic, but it can be semantically deterministic. As he explained, "it's basically semantically deterministic," meaning the model produces different wording that carries the same meaning for the application.

That reframes what a team needs to guarantee. You are not chasing identical strings. You are checking that the system reaches the same decision. When a recommendation model has 17 or 25 choices, the test is whether it picks the same choice every single time. Iyer notes that engineering controls such as fixing the random seed can force the same output from the same input, but the deeper shift is learning to accept semantic equivalence instead of literal equivalence. Teams new to this find it hard.

Daianu draws the line between the two model types directly. Deterministic machine learning has a finite set of responses, like a recommendation system with a fixed menu. A nondeterministic language model can express itself in an infinite number of ways, which is where hallucinations enter and where compliance gets hard. Her team accepts the probabilistic model because it adds value, then constrains it hard enough to stay safe. Cotton put the trade-off plainly: teams use the nondeterministic technology because it works, and they would not tolerate it otherwise.

Catching hallucinations: the prelaunch and postlaunch evaluation framework

Daianu walks through a two-part evaluation framework: prelaunch checks before anything ships, and postlaunch monitoring once it goes live. The prelaunch checklist starts with the training data itself. Language models absorb statistical bias, and she gives a concrete case. Many credit cards carry a $0 benefit, so a model trained on that data tends to predict $0 for almost everything. When a card does have a benefit, that prediction is wrong, and in fintech a wrong benefit is a compliance failure. As Daianu put it, "we absolutely we cannot say that." So the first step is de-skewing the data, often through fine-tuning.

The second layer uses larger language models as judges, which reason better but are not enough alone. Credit Karma pairs them with a dynamic tagging system that encodes which specific benefits and rules matter for a given card, so the judging model checks those points and does not brush over them. The third layer is humans in the loop: product managers, legal experts, and compliance experts review a subset of outputs, and their labels feed back into the system as training data.

The accuracy bar is unforgiving. As Daianu put it, "96% accuracies, for instance, is not enough," because a single hallucinated benefit on a summary breaks trust with both users and partners. After launch, the same components monitor live output and flag anything off, including tone that drifts from the voice of Credit Karma. Iyer adds a nuance from his own evaluation work. Some subclasses of a problem can run at 100% accuracy while others sit near 30%, and the evals tell you exactly which patterns work. That lets a team ship generative AI for the safe subclasses and hold it back where the numbers say no. It also answers where AI fails: he found underwriting rules involving relatives, ages, or dates needed intervention, while the rest was mostly reliable.

Build versus buy, latency, and the skills that separate shippers

Daianu states a clear build-versus-buy rule. Build the layers that give you a competitive advantage, such as an approval-odds model trained on user data only you hold. Buy the parts that change fast, such as commercial language models and GPU infrastructure. As she put it, "there's no reason to reinvent the wheel." Cotton noted the logic: most companies do not want to compete with NVIDIA on GPUs or with frontier labs on models, so effort should go where the company can actually differentiate.

Latency forced a related decision. When Credit Karma first built its generative assistant layers more than two years ago, answers could take over ten seconds, which she says is not a valuable product. Her team moved from large commercial models to smaller fine-tuned open-source models, specialized for their use cases through techniques like the tagging system. Those models run faster and cost less, and they reduce the engineering churn of migrating every time a commercial model changes. She notes the industry tried fine-tuning, dropped it as harder than expected, and is now returning to it.

On skills, Iyer separates one habit that helps everyone from one that marks out strong practitioners. The first is using AI to learn on demand. He says the smarter move is not asking a model to do the task, but asking it "what are the things that I need to worry about or what are the things that I need to learn." Across 180 use cases, he never once avoided learning something new. The second skill is running evaluations, which he treats as a data science discipline. As he put it, "it's very difficult to get anything into production without being really good at evals." Daianu adds the human traits that scale: curiosity, first-principles thinking, and sound judgment, especially as strong individual contributors start to manage agents rather than only people.