.svg)
Most financial institutions aren’t short on ambition when it comes to AI. Executives want a strategy, boards want a story for investors, and every vendor conversation begins with some version of “how are you thinking about AI?”. What’s actually missing is a clear answer to where to start, what to trust, and what to build versus buy.
This guide is about that starting point. Less about the destination, more about the first 18 months of decisions that determine whether AI becomes something a bank actually runs on, or another initiative that quickly stalls after the pilot.
Talk to enough financial institutions, and you’ll begin to see a pattern: almost everyone has something running. Some fraud teams have had machine learning models in production for years, and marketing has probably experimented with a chatbot or a recommendation engine. But very few institutions have moved past isolated pilots into something that touches the core business consistently.
There are good reasons for that, and not all of them are about limited capacity, being risk-averse, or even cultural resistance. Banking architecture wasn’t designed with AI workloads in mind. Data lives in a dozen different places, in a dozen different formats, updated on a dozen different schedules. And the regulatory environment is a lot more complex for a bank than it is for a retailer experimenting with the same technology. A model that gets a product recommendation on a clothing website wrong is a minor inconvenience; one that gets a lending decision wrong is a fair lending problem.
But none of this means AI should wait.
It’s tempting to start by evaluating models: which LLM should we use, which vendor, which architecture? But that’s usually the wrong first question. A model is only as useful as what it’s looking at, and most banks’ customer data is scattered across core banking systems, CRM platforms, card processors, and channel logs that were never designed to talk to each other.
Before any AI initiative can deliver something reliable, that data needs to be unified and understood. Transaction data needs to be categorized and enriched so a model can tell the difference between a mortgage payment and a transfer to a savings account. Customer records need to be reconciled across systems so the same person isn’t three different profiles in three different databases. This work is perhaps unglamorous, but it’s the difference between an AI pilot that works in production and one that only ever works on a clean demo dataset.
The institutions that make real progress tend to resist the instinct to launch an “AI strategy” as an abstract initiative. Instead, they pick a specific, bounded problem with a clear before-and-after.
A few examples that tend to work well as a first step: personalized nudges that prompt a customer to move idle cash into a higher-yield account, anomaly detection that flags unusual transaction patterns before a customer calls in confused, or a frontline tool that gives branch staff a fuller picture of a customer’s financial position before a conversation starts.
What these have in common is that success is easy to define. Did more customers move cash? Did fewer fraud cases turn into losses? Did the average call resolution time drop? A first use case with an unclear definition of success will struggle to earn the internal buy-in needed for a second one.
Very few institutions have the internal capacity to build banking-specific AI models from scratch, and fewer still should try to do so for their first project. The realistic question is usually not build or buy, it’s which layer to own. Most banks are better served focusing their internal resources on the customer-facing use case, the actual product experience, while working with a partner for the underlying data infrastructure and model layer that makes that experience possible on top of messy, real-world banking data.
This is where a platform like Bud tends to sit. Bud unifies a bank’s core, CRM, and channel data into a single real-time customer object, built with models trained specifically for banking data, so internal teams can focus on turning that intelligence into the right product for the right customer at the right time.
Explainability, auditability, and bias testing shouldn’t be treated as a compliance checklist that gets attached at the end of a project. In banking more than many other industries, the ability to explain why a model made a decision is part of the product, not an add-on to it. A recommendation engine that can’t explain its reasoning to a regulator, or to the customer it affected, isn’t ready for production regardless of how accurate it is.
The institutions that move fastest over time are usually the ones that treat trust as a competitive advantage rather than a constraint. It stands to reason that customers are more willing to share data and act on AI-driven suggestions when they understand, even at a high level, why they’re being made.
It’s worth being honest about what a realistic marker of success looks like early on, because the language of “transformation” tends to set expectations no first project can meet. A good six-month outcome usually looks like a pilot with clear, measurable results, a data foundation that’s stronger than it was, internal stakeholders who’ve seen enough to back the next use case, and a repeatable process for evaluating what comes after it.
What that looks like in practice varies by use case, but it’s specific. A lending team might point to fewer rejected applications because affordability checks are working from a fuller picture of income and spending, not just a credit score. A marketing team might point to a higher click-through rate on in-app offers because targeting is based on actual account behaviour rather than a broad segment. A contact centre might point to shorter average call times because staff can see a customer’s full financial picture, and next-best actions, before the call even starts. In each case, the number existed before the project began, and the project moved it in a direction someone can defend in a budget meeting.
Getting started with AI in a financial institution is less about choosing a model and more about getting the data and governance right, before a model ever sees production traffic. The banks that treat this as an infrastructure and data maturity problem first tend to end up further ahead than the ones that jumped straight to a pilot. The model is rarely the hard part. The foundation underneath is.
If your team is figuring out where to start, Bud can show you what this looks like on your own data. Book a demo here to talk through your first use case.
%201.webp)
