N/HNajmul Hussain

framework · ai in banking · 2 min · 5 steps

Before you switch on a vendor's AI agent: a five-step check

Core and technology providers are now shipping AI agents that act inside banks' systems. Here is what to establish before the first one goes live.

use_this_when→ Your core or technology provider is offering an AI agent that reads or changes data in your systems→ An agent will touch a regulated process such as AML, lending or complaints→ Procurement is treating the agent as a feature of an existing contract

Najmul HussainMay 31, 2026 · 2 min read

A blue-lit server room with cabling and a monitor — Photo: panumas nikhomkhai / Pexels

tl;dr

→ In May 2026 FIS (with Anthropic) and Fiserv both announced AI agents that work inside banks' core and operational systems.
→ These agents act, not just advise, so they need the scrutiny of a new employee with system access, not a software feature.
→ Five checks cover the essentials: scope, permissions, human control, evidence and exit.

May 2026 was the month core banking providers started shipping AI agents. On 4 May FIS announced it is building a Financial Crimes AI Agent with Anthropic, designed to assemble evidence across a bank's core systems, evaluate activity against known typologies and draft suspicious activity report narratives, with investigators keeping control of every decision^[1]. BMO and Amalgamated Bank are among the first institutions developing with it, with general availability planned for the second half of 2026. Ten days later Fiserv launched agentOS, a platform to run its own and partners' agents across its core, payments and servicing systems^[2].

Both providers put governance at the centre. FIS says every agent decision is traceable and auditable and client data stays within its controlled infrastructure; Fiserv lists identity-bound execution, policy enforcement and human oversight.

Vendor governance is necessary, but it is not the bank's governance. When an agent reads customer data, assembles an AML case or prepares a lending decision, the bank remains accountable to its supervisor for the outcome. The five checks below are what I would complete before any vendor-supplied agent touches a regulated process. They take weeks, not months, and they make the difference between an agent you can defend and one you have to explain.

01
Define the agent's job in one paragraph
Write what the agent does, what it must never do, and which decisions stay with people. If the vendor cannot help you write it, the agent is not ready for a regulated process.
02
Give it the least access that works
Map every system and data set the agent can read or write. Start read-only where possible, and make write access specific to named actions and limits.
03
Keep a human decision point
For regulated outcomes, such as filing a suspicious activity report or declining a loan, the agent prepares and a person decides. Record who decided and on what evidence.
04
Demand evidence you can show a supervisor
Every recommendation should come with the data it used and the reasoning it followed, retained for as long as the underlying records. Test a sample before go-live.
05
Agree the exit before the entry
Know how to switch the agent off without disrupting the process, what happens to its logs and prompts, and whether your configuration is portable to another provider.

your_progress0%

0 of 10 actions done · saved on this device

key_takeaways

01An agent that acts inside your systems is closer to an outsourced colleague than to software.

02Human decision points are not a brake; they are what makes the output defensible.

03Exit terms are cheapest to negotiate before the first agent goes live.

the_ledgerGet the next one in your inboxOne sharp idea on banking strategy, every other Tuesday.

sources

AI in Banking Risk & RegTech

want_to_run_this?Run it with your team in a half-day workshop.Ask about a workshop →

relatedTurning Treasury's AI risk framework into a working programme From prompt engineering to context engineering Amex's $350m AML penalty puts card flows inside the risk assessment