Are you a CTO at a digital-first bank or lender who is disappointed with your AI initiative?
Have you run pilots for credit scoring models, customer churn prediction, fraud detection, or personalised product recommendations?
Maybe the demos looked promising, the vendor presentations were compelling, and the business case seemed solid, but six months later, the pilot is still a pilot. Or worse, it’s been shelved while your team moves on to the next initiative.
Maybe you’ve experienced some of these barriers:
- The model wasn’t accurate enough
- You couldn’t get buy-in from risk
- The implementation was more complex than expected
- You didn’t see the ROI you anticipated
The truth is, each of these is a symptom, not the cause. The real reason most AI pilots fail to scale — as many as 95%, according to research reported by MIT — for financial institutions has nothing to do with the sophistication of the algorithms or the talent of your data science team.
The real reason is infrastructure. Specifically, your core banking system and the data layer
sitting on top of it.
Here’s why this matters, what’s actually going wrong, and what you need to fix before your
next AI initiative has any chance of success.
The AI promise versus the AI reality
The promise of AI in banking is compelling and well-documented:
- Reduce credit risk through better underwriting
- Increase revenue through personalised offers
- Lower fraud losses through real-time detection
- Improve retention by predicting and preventing churn
Many digital-native fintechs and tech-forward banks in markets across Asia and Africa are
achieving exactly these outcomes. But there’s a critical difference between institutions where AI is working as intended and those where it remains perpetually in pilot mode.
That difference isn’t the AI itself. It’s the foundation the AI sits on.
Example: Here’s what typically happens in a failed AI pilot. A financial institution decides to build a machine learning model for credit scoring. The goal is to approve more customers, faster, with lower default rates than traditional scorecards allow. The data science team gets hired or contracted, they request data, and this is where everything starts to unravel.
Because the data they need, including transaction histories, repayment behaviour, and
account activity patterns, is scattered across multiple systems. This data is spread across a fragmented core banking platform, loan management system, mobile app database, payment processor, and maybe even some spreadsheets in operations. Each system has its own schema, its own definitions, and its own version of the truth.
Getting access to this data requires tickets to different vendors, extraction scripts that need IT approval, data dumps that happen periodically, and weeks of work just to understand what the fields actually mean. By the time the data science team has something to work with, it’s months old and incomplete.
But they persist. They build a model, it performs well in testing, and worst of all, everyone
gets excited.
Then comes deployment. To use this model in production, it needs to receive real-time data about new loan applications. Then it needs to return a decision that feeds back into the core banking system’s approval workflow. Lastly, it needs to log its predictions for monitoring and compliance.
And now is the moment when you discover that your core banking system doesn’t have APIs for this. Or the APIs exist but don’t expose the fields the model needs. Or maybe there’s no way to inject the model’s output back into the approval process without manual intervention.
Or maybe, even, the vendor says yes, they can do it…for a custom development project that will take nine months and cost six figures.
And so the pilot dies. Not because the AI didn’t work, but because the infrastructure couldn’t support it.
Why legacy cores are AI-hostile
Most core banking systems in use today were designed 15 to 20 years ago, long before
machine learning became accessible and practical for financial services. They were built
around batch processing, scheduled reports, and human decision-making workflows.
These systems are fundamentally hostile to AI, and here’s why:
No real-time data access
AI models need data flowing continuously, not extracted monthly. A fraud detection model is useless if it analyses yesterday’s transactions and a churn prediction model can’t help if it runs once per quarter. Models need to see patterns as they emerge, not after the fact.
Legacy cores typically expose data through scheduled reports, database dumps, or extract files. Even when APIs exist, they’re often designed for synchronous queries rather than streaming event data.
If your core can’t stream transaction events, balance changes, and user behaviours in real
time, you cannot deploy AI models that require current data.
Inconsistent data definitions
There are a great number of financial institutions where active customer has three different definitions depending on which system you query. But machine learning models are incredibly sensitive to data quality and consistency.
Train a model on data where declined transactions are defined one way, then deploy it in an environment where the definition is different, and the model’s performance collapses. The problem isn’t the model, it’s that it’s operating on different data than it was trained on.
Legacy cores accumulate these inconsistencies over years of patches, customisations, and workarounds. Each vendor integration adds another schema and each product launch adds new fields that don’t quite align with existing ones. The result is a data environment that’s nearly impossible to model reliably.
No mechanism to operationalise predictions
Even if you manage to build a model and generate predictions, how do those predictions
actually affect business outcomes?
- A churn prediction model is worthless if it can’t trigger a retention campaign
- A credit scoring model is useless if it can’t feed into the approval workflow
- A fraud model is pointless if it can’t block suspicious transactions in real time
This requires tight integration between your AI systems and your operational systems,
particularly your core banking platform. Ultimately, the model needs to receive data, generate predictions, and send those predictions back into workflows that take action.
Legacy cores weren’t designed for this kind of bi-directional, real-time integration. They
expect humans to make decisions and input them manually. Automating those decisions
through AI requires APIs, event triggers, and workflow hooks that most legacy systems
simply don’t provide or provide only through expensive custom development.
Lack of auditability and explainability infrastructure
Financial services are heavily regulated, and regulators increasingly want to understand how automated decisions are made. If an AI model declines a loan application, you need to explain why, not just to the customer, but to auditors and compliance teams.
This requires infrastructure that logs model inputs, outputs, versions, and decision rationales in a way that’s auditable and traceable.
Most legacy cores have no concept of this because they were designed for human decision-making, where the audit trail is which officer approved which application. When you try to layer AI on top, you’re often building this audit infrastructure from scratch, outside the core, which creates compliance risk and additional operational complexity.
The data layer problem for AI in banking
Even institutions that recognise their core banking limitations often try to solve the AI
problem by building a separate data layer; a data warehouse or data lake that consolidates information from multiple systems.
This is the right instinct, but execution matters enormously. Too many data layer
projects become expensive, multi-year initiatives that still don’t enable AI in production.
Here’s what typically goes wrong:
Batch-oriented ETL pipelines
Many banking data layer implementations use nightly ETL processes that pull data from source systems once per day. This creates a data warehouse that’s always out of date. You cannot run real-time AI on yesterday’s data.
Real-time AI requires streaming data pipelines or near-real-time replication where changes in the core banking system are reflected in the analytics database within seconds or minutes, not hours or days.
No operational write-back
Many data warehouses are read-only by design; they’re built for analytics and reporting, not operational workflows. This means even if you train a model on this data, you can’t easily deploy that model in production because there’s no path to write predictions back into the operational systems that need them.
You end up with lovely dashboards and sophisticated models that produce insights nobody can act on because the insights can’t feed back into the systems that run the business.
Governance and access bottlenecks
In many financial institutions, the data layer is controlled by a centralised data team or IT
department. Want to add a new data source? Submit a ticket. Want to modify a
transformation? Wait for the next sprint. Want to understand what a field actually means?
Good luck finding the documentation.
This creates a bottleneck where data scientists spend more time navigating organisational
processes than building models. The promise of AI was supposed to be speed and agility.
Instead, you’ve recreated the same vendor dependency problem you had with your legacy
core, just with an internal team instead of an external vendor.
What AI-ready banking infrastructure should look like
After seeing enough failed AI pilots, you start to recognise the patterns in institutions where AI works. Here’s what AI-ready infrastructure looks like in practice:
Event-driven, real-time data access
Every significant action in the system, from a transaction to a balance change, to a loan
application, to a missed payment, generates an event that’s immediately available to
downstream systems, including AI models. This can be implemented through event streams (like Kafka), database replication, or change data capture (CDC) mechanisms.
The key is that data is flowing continuously, not extracted in batches. Models have access to current state, not historical snapshots.
Clean, consistent data schemas
Someone must do the hard work of establishing canonical definitions for critical entities and events. This doesn’t mean perfect data quality, but it does mean the data is reliable enough to train models on and deploy them confidently in production.
APIs for bidirectional integration
The core banking platform exposes APIs that let external systems (including AI models) both read data and write back actions. A credit scoring model can receive application data via API, return a score and decision, and have that decision automatically reflected in the approval workflow.
This requires the core to be genuinely API-first, not APIs bolted onto a legacy system as an afterthought. The difference shows up in what you can do without vendor involvement.
Governed but accessible data layer
Teams building AI models need direct access to data without submitting tickets and waiting weeks. But this access needs to be governed. The right people see the right data, usage is auditable, and there are guardrails to prevent production systems from being impacted by experimental queries.
This is exactly why we built Database Access—a secure, read-only replica of the production database that stays in sync automatically and lets data teams query directly without putting load on live systems or waiting for IT tickets. Your data scientists can explore, build, and iterate, your governance team can audit who accessed what, and your production systems stay protected.
Model deployment infrastructure
There must be a clear path from the model working in testing to the model running in
production. This might be containerised deployments, serverless functions, or embedded logic within the core platform itself. The point is that deployment isn’t a multi-month vendor project, it’s a standard engineering workflow that your team controls.
Audit and explainability built-in
Every model prediction is logged with enough context to understand why the decision was
made. Model versions are tracked and when regulators or auditors ask why a certain customer was declined, you have a clear, auditable answer.
Assess whether your core and data layer are AI‑ready before your next pilot.
Why this matters more now than ever for financial institutions
We’re entering a period where AI capability is becoming a competitive differentiator in
financial services. Institutions that can approve creditworthy customers others miss, detect fraud before it happens, retain customers who would otherwise churn, and personalise products to individual needs will win market share.
But AI capability doesn’t come from buying the fanciest models or hiring the most data
scientists, it comes from having infrastructure that truly makes AI deployable in production.
The gap between AI-ready institutions and AI-aspirational institutions is widening. The
institutions with modern, cloud-native cores and proper data layers are deploying models in weeks, learning from production data, iterating rapidly, and compounding their advantages.
Meanwhile, institutions on legacy cores are still trying to get their first pilot into production, fighting with vendors over API access, reconciling inconsistent data, and wondering why their AI investments aren’t delivering ROI.
Diagnose what’s holding your AI back
If your AI pilots keep failing, stop blaming the models and start looking at the foundation.
Here are the questions to ask:
- Can your data science team access production data directly, or do they need to
submit tickets and wait weeks for extracts? - Is the data they access real-time, or batch-updated nightly?
- Can a model’s predictions feed back into operational workflows automatically, or does someone need to manually input them?
- Does your core banking platform expose APIs that let you inject custom logic and business rules?
- Can you audit and explain every model decision with confidence?
If you’re answering no to most of these questions, your AI problem is an infrastructure
problem. And infrastructure problems don’t get solved by buying better AI tools—they get
solved by modernising your core banking platform and data layer.
Turn insight into action with our 90‑day AI pilot planning template.
Oradian: Your key to AI success this year
The good news is that solving infrastructure problems solves more than just AI in banking. An institution that builds AI-ready infrastructure through real-time data access, clean schemas, bidirectional APIs, and governed data layers also builds infrastructure that enables faster product launches, better user experiences, and data-driven decision-making across the organisation.
This is why we built Oradian the way we did.
- Cloud-native from day one
- API-first
- Database Access for direct data querying
- Custom Code for deploying business logic without vendor dependency
Because we’ve seen too many institutions with brilliant AI strategies held back by
infrastructure that wasn’t designed for it.
Your next AI pilot doesn’t have to fail. But it probably will, unless you address the foundation first.
The institutions that win with AI in 2026 won’t be those with the most sophisticated algorithms, they’ll be the ones with infrastructure that makes those algorithms deployable, scalable, and valuable in production.
Which one will you be?
Drop us an email at vanda.jirasek@oradian.com to make this year the year you succeed at activating and leveraging AI.
Get the whitepaper: The digital-first bank’s guide to AI in 2026
This article provides a taster for our full guide, which shows you how to build the foundation that makes AI actually work. We cover everything from credit scoring with alternative data to operational automation that cuts costs by 40%. But most importantly, we show you why your data layer matters more than any algorithm and how to fix it before you waste money on AI that goes nowhere.
