.avif)
Generative AI in banking pilots are not stalling because banks picked the wrong use cases. MIT's NANDA initiative found that 95% of enterprise generative AI pilots produce no measurable impact on the P&L, and BCG reports that fewer than 10% of banks use generative AI effectively in daily operations, even though most have already launched one. The use cases themselves are well understood. What is not solved yet is implementation: legacy integration, data governance, and compliance sign-off. This guide covers five generative AI in banking use cases with real production deployments, the specific challenges each one hits, and how to avoid the point where most projects stall before reaching production.
Credit scoring and fraud detection have used AI for years, but that work is predictive machine learning. The five use cases below are where generative AI specifically applies.
Generative AI chatbots read customer intent and respond in natural language, but a chatbot answering correctly in a demo and a chatbot answering correctly against live account data are different engineering problems. According to Backbase, 63% of banks report difficulty connecting chatbots to legacy core banking systems. The model functions, but it cannot read or write to the actual system of record, so it answers from whatever fragment of data it was given at build time.
Three problems compound the integration gap:
Wells Fargo's Fargo assistant shows what the fix looks like in production. The assistant processed over 245 million interactions in 2024 with zero PII exposed to the underlying language model, using a privacy orchestration layer that strips and tokenizes customer data before it ever reaches the model.
If your team has launched a chatbot and customers are getting wrong answers, or the bot cannot connect to your core system, or nobody has defined what happens when it cannot answer, the fix is architectural. It has to happen before the model is built, not inside the conversation flow.
If your chatbot is stuck on the same integration wall, an AI Launch Readiness Assessment maps exactly where your coresystem, your data layer, and your governance model are blocking production.
Book an AI Launch Readiness Assessment.
Banks weighing where generative AI belongs in the customer-facing layer at all can see a related build-versus-augment tradeoff play out in practical AI use cases in fintech underwriting, a different workflow with the same governance question underneath it.
Generative AI reads unstructured documents, loan applications, regulatory filings, contracts, and extracts, summarizes, or classifies what is in them. This is different from OCR, which reads characters. Generative AI reads meaning, which is exactly why it introduces risk that traditional document automation never had.
Four issues make this harder than a document summarizer sounds:
Citigroup's rollout shows the compliance-safe version of this use case. The bank gave roughly 140,000 employees access to Citi Assist and Citi Stylus, internal tools that summarize and compare documents, with consent-order controls built into the deployment from the start. In one disclosed case, Citi cut an account opening document review from 60 minutes to 15 minutes, a 75% reduction in review time.
Ideas2IT's own retrieval work for Protocol Labs points at the same architecture problem from a different angle. Cutting retrieval time from 15 minutes to 30 seconds came from rebuilding how the underlying documents were indexed and queried, not from making the model smarter.
If compliance is blocking a document AI deployment, the model summarizes things incorrectly and you cannot use the output, or you do not know how to get a deployment past model risk management review, a Maturity Assessment Workshop identifies exactly where your architecture falls short.
Book a Maturity Assessment Workshop.
For the compliance layer specifically, see how AI governance in finance gets structured, and what financial software compliance requirements look like once a document AI system is live.
Wealth management runs on proprietary product knowledge that a general-purpose model was never trained on. An advisor asking about a firm's specific fund structure or internal product classification gets an answer that sounds confident and is wrong, because the model is pattern-matching against public knowledge instead of the firm's actual documentation.
Four factors raise the bar past what a typical chatbot deployment has to clear:
Morgan Stanley's deployment is the clearest production benchmark here. The firm's AI assistant, built on GPT-4 in partnership with OpenAI, indexes roughly 350,000 research reports and documents and is used by over 98% of advisor teams, cutting a research lookup that used to take 30 minutes down to seconds by grounding every response in a citation from the source document.
The same retrieval architecture problem shows up in Ideas2IT's Protocol Labs engagement, where restructuring how documents were indexed cut retrieval time from 15 minutes to 30 seconds, the same pattern wealth management advisory requires at a different scale.
If advisors are spending hours searching internal documents, you cannot trust the model's answers enough to put them in front of a client, or you are not sure how to index internal documents without exposing them to a third-party model, a Maturity Assessment Workshop scopes what a grounded retrieval system actually requires.
Book a Maturity Assessment Workshop.
For the underlying model decision, see how LLM operations for enterprise affects retrieval accuracy at scale, and what generative AI development looks like when the deliverable is a grounded internal knowledge system.
Generative AI's specific role in anti-money laundering is Suspicious Activity Report narrative generation, not transaction scoring. Transaction scoring is traditional predictive machine learning and has been in place for years. The generative AI layer reads the flagged transaction data an investigator has already reviewed and drafts the regulatory narrative that explains why the activity was flagged.
Four constraints define what a defensible deployment looks like:
The direction the market is moving is visible in academic and vendor work on SAR generation, including agentic frameworks built specifically to keep an investigator's reasoning chain intact in the final narrative, which is the same auditability requirement banks are being held to.
Ideas2IT's FEGO engagement, which delivered three open finance products in eight months, reflects the same delivery pattern this use case needs: financial services work built around compliance architecture from day one rather than retrofitted after a model is already in production.
If your compliance team gets more alerts than it can turn into filed SARs, if you are weighing whether SAR filing can be automated at all, or if you need to prove to a regulator that an AI-assisted SAR is defensible, an AI Launch Readiness Assessment maps what your auditability gap actually is.
Book an AI Launch Readiness Assessment.
For the modeling layer underneath AML narrative generation, see how ML model engineering supports both the predictive scoring and the generative narrative layer without treating them as the same system.
Personalization at scale depends on data quality more than model quality. A model trained on siloed or incomplete customer data will send the wrong offer to the wrong customer, and a wrong personalized offer damages trust faster than no personalization at all.
Four constraints shape what a compliant personalization program can actually do:
McKinsey's research on personalization found that fast-growing companies derive 40% more of their revenue from personalization than their slower-growing peers. Applied to banking, that means generating multiple compliant variations of a single offer, each pre-filtered for FCRA and UDAP compliance, and testing them at scale.
If your personalization engine is triggering opt-outs instead of conversions, your content team cannot keep up with the variations a real program requires, or you are not sure how to stay compliant while personalizing credit product recommendations, a Maturity Assessment Workshop identifies where the data and compliance gaps sit.
Book a Maturity Assessment Workshop
For the delivery side of this problem, see what custom financial software development looks like when the goal is unifying marketing, transaction, and service data into one system a model can actually query.
MIT NANDA's finding, that 95% of enterprise generative AI pilots show no measurable P&L impact, is not a banking-specific number, but banking's own data tells a similar story. BCG reports fewer than 10% of banks use generative AI effectively in operations, and a separate BCG survey found only 25% of banks have woven AI into their strategic playbook at all. Most are still running pilots that never left the sandbox. For a broader look at why this pattern repeats across industries, not just banking, see enterprise AI implementation pitfalls.
Four reasons explain the gap:
If any of this sounds familiar, the use case was never the blocker.
The decision comes down to five factors: process type, data readiness, architecture maturity, governance capacity, and talent availability.
Partner is the right call when the constraint is complex legacy integration, regulatory governance requirements that need to be built in from the start, or a mid-market bank without a dedicated machine learning team. This is the category most of the use cases above fall into, because the hard part was never the model. It was the legacy core, the compliance documentation, and the ownership structure around the model once it is live. An AI implementation partner that has already built that architecture for other regulated institutions gets a bank to production without rebuilding the governance layer from scratch, and agentic AI development extends that same foundation once a use case moves from answering questions to taking action.
Banks weighing this decision against staffing constraints should also look at how Plug & Play AI Pods fill the gap between full build and full outsourcing.
Three regulatory developments define what compliant deployment looks like right now.
The OCC, Federal Reserve, and FDIC's bulletin replaces the prior SR 11-7 framework with a single interagency standard, and the agencies have signaled that AI-specific guidance, covering generative and agentic models directly, is still to come. The practical implication is the same across every use case in this guide: model risk management documentation, validation, and explainability have to be built in from the first line of the pilot, not retrofitted once the model works.
Every use case in this guide breaks in the same place: not the model, but the integration layer, the compliance documentation, and the ownership structure once the system is live. That is the specific gap Ideas2IT's financial services work is built to close.
Ideas2IT holds SOC 2 Type II and ISO 27002 certification. It also carries an AWS Partner GenAI Competency badge. Those matter directly for how customer and transaction data gets handled in every use case above, and they extend the same generative AI development services and ML model engineering work referenced earlier into a compliance-first delivery model.
In financial services specifically, the FEGO engagement delivered three open finance products in eight months, built around compliance architecture from the first sprint rather than retrofitted after launch. Ideas2IT has also worked with Oportun on financial services engineering. The Protocol Labs engagement, cutting retrieval time from 15 minutes to 30 seconds through better AI data services and retrieval architecture, is the same technical problem underneath the document intelligence and wealth management use cases above.
Three entry points fit where most banks actually are:
Most banks reading this are in one of four places: a use case identified but no clear starting point, a pilot that stalled before reaching production, a model risk management sign-off that will not clear, or no defined data infrastructure to support scale.
Book an AI Launch Readiness Assessment
An AI Launch Readiness Assessment gives a direct answer to where you sit. You get a clear read on whether your use case is viable as scoped, what the implementation path to production actually requires, and what compliance requirements apply to your specific deployment.
We'll tell you whether your use case is viable, what it will take to go to production, and what the compliance requirements are for your specific context.
Get started here.
Didn't find what you were looking for?
