Where should AI sit in a bank's core?

By Ove Kreison, CPTO, Tuum ·  Oct 19, 2026

AI models are probabilistic. Ask the same question twice and you can get two different answers.

A ledger has to be deterministic. The same transaction must post the same way every time, and an auditor must be able to trace exactly why.

When the numbers have to be right every single time, a system that works in likelihoods can’t be the thing you trust to keep them. So every bank adding AI has to decide where it sits in relation to the core.

An around-the-core approach

One architectural answer is to keep AI around the core. AI connects through the same controlled APIs as every other system. It reads, analyzes and recommends, while the core keeps the record, applies the rules and behaves the same way every time.

There’s a commercial logic too. The best model today won’t be the best model in 12 months. When the core and the AI sit in separate layers, each doing its own job, the bank can switch models as the market moves without touching the ledger. That portability lets a bank adopt whatever the AI ecosystem produces and whatever customers start expecting next.

Where the AI sits decides how your regulator reacts

Regulators worry about three things with AI: decisions nobody can explain, models nobody validated, and dependencies nobody can exit. Every one of those problems gets worse when AI sits inside the system of record.

Under the EU AI Act, AI that judges whether a person gets credit counts as high-risk. Banks have to document how it works, log every decision, and keep a human able to overrule it. That’s far easier to prove when the AI sits outside the ledger and every action runs through logged, permissioned APIs.

DORA asks EU banks to manage concentration risk with their tech providers and keep a workable exit plan. An AI layer you can unplug is far easier to defend than one built into your ledger.

And in the US, banking regulators’ guidance on model risk spells out what supervisors expect: any model behind a material decision has to be documented, validated and open to challenge, so someone else can trace the result and get the same one again. The bank stays responsible for that model even when a vendor built it. Keeping AI outside the ledger is how you stay inside the rules.

Supervisors in the GCC and Asia are asking the same questions in their own frameworks.

Here’s what an around-the-core architecture gives a compliance team:

• Every AI action leaves the same trail as a human one. Agents go through the same validated APIs and the same checks as a staff member. The audit log doesn’t need a separate chapter for AI.
• Swapping a model is a change to one integration. When the model sits outside the core, replacing it means testing that connection. When the model sits inside, replacing it can mean re-validating the system of record, and that’s a conversation nobody wants to have with their supervisor.
• The rules stay where the bank sets them. Interest calculations, limits and product terms live in configuration that AI can’t alter. A model can recommend a change. A person approves it.
• The bank keeps a credible exit plan. If an AI provider fails, gets acquired or falls behind, the bank disconnects it and connects another. The core, the data and the customer records stay exactly where they are.

What to look for in a core built for AI

This approach is often called agentic architecture: a core that’s AI-capable today and ready for whatever AI brings next. It should be open to anything worth connecting and closed to anything without permission. In practice, banks should look for five things.

• Validated APIs only. AI agents reach the core through the same APIs as every other integration, so core logic is never bypassed.
• Guardrails AI can’t override. Every AI interaction passes the same validation as a human input, and no AI can alter foundational rules.
• Clean, real-time data. A granular data model and event streams that can feed fraud engines, decisioning platforms and retrieval models as transactions happen.
• A configuration layer the bank controls. New products and new regulatory rules land as configuration changes, with no code written.
• Freedom to choose the AI. The bank can plug in whatever leads the market today and swap it for something better next year without touching the ledger.

Putting AI to work around the core

Some of the most valuable AI work in a bank happens one step away from the ledger. AI reads, analyzes and recommends, and the core records the outcome.

• Migration. Most banks run on decades of undocumented code. AI can help uncover every dependency and buried business rule in a legacy system before a single record moves, write the tests the migration needs, and help break the monolith into smaller services.
• Fraud detection. Clean, real-time data from the core lets a bank plug in a fraud engine, most likely one that runs on AI, to check every payment against the customer’s normal behavior as it happens. Because the fraud engine sits outside the core, the bank can swap in a better one whenever it appears.
• Regulatory change. When a rule changes, AI can trace every product and process it touches, so the compliance team starts with a full list instead of a guess. The change itself still lands as configuration that a person reviews and approves.

Questions every bank should ask its core vendor

• Which decisions does a model make inside the ledger, and which happen outside it?
• Does AI reach the core through the same validated APIs and checks as our staff?
• If we switch to a different model next year, what do we have to re-validate?
• Can we connect AI from other providers, or only yours?
• Can you show us the audit trail for one action an AI agent took last week?

The answers show where a vendor’s AI actually sits, and how much control the bank keeps over its own roadmap.