Why Your Banking AI Agent Works But Still Can’t Go Live

Let’s say you’ve just finished building a banking AI agent that onboards high-net-worth clients. 

You’ve spent weeks rigorously testing it, and the pilot confirms that the agent handles complex cases correctly and cuts onboarding time significantly.  

Leadership is eager to roll it out. 

You send the agent to the review team for final approval before it goes live.

A few days later, the response comes back saying that the agent cannot go live. 

You’re shocked because the agent works exactly as expected.

So why wasn’t it approved?

To answer that, you first need to understand who this review team is and what they actually do.

Inside every bank is a team responsible for reviewing AI agents before they are allowed to go live. They sit between the developers who build the agents and the regulators who audit the bank.

In many banks, this team is called the Model Risk team. 

Their job is to make sure every AI decision can be explained if a regulator asks about it.

Imagine a regulator walks into the bank six months later and asks, “Show me exactly how this high-net-worth client was onboarded.”

The bank has to answer that question clearly. That means answering questions such as:

• Why was this decision made? 

• Which version of the AI model made that decision? 

• What evidence did the model use? 

You’re probably wondering what could be missing. After all, observability tools like LangSmith already capture every step the agent took.

But the model risk team is asking something else entirely.

Let me show you what they are looking for, using the onboarding agentic AI system I built as a working prototype for this series. If you want to understand how the complete system works, the full walkthrough is here.

Take a client like James, who sold his software company for $18 million and wants to transfer $5 million into a new Canadian bank account.

The onboarding AI system processes James’s application using several specialist agents.

One verifies his identity.

Another screens him against sanctions and regulatory watchlists.

Others review his wealth, source of funds, and business history.

Together, those agents assess James’s application and prepare a complete case for the compliance officer.

The case shows how risky James is as a client, what has already been verified, and what still needs the officer’s attention.

When the system finishes processing James’s application, it leaves behind a complete record of every step it took

Here is what the agent trace looks like in LangSmith, the tool we use to monitor the onboarding system.

You can see which agents ran, how long each one took, and what each agent received and returned. The entire run finished in under a second.

Now, let’s look at the case summary agent’s output for James, copied exactly from the trace.

James Whitmore, a HIGH-risk client, is being onboarded for high-net-worth
services.

WHAT HAS BEEN VERIFIED
- Identity verification is complete, confirming James Whitmore's identity
- No sanctions match was found, indicating James Whitmore is not on any
  watchlists
- Wealth documents and bank statements are present, providing a clear
  picture of his financial situation
- Business sale context is supported by documents and registry, explaining
  the source of his wealth

WHAT NEEDS REVIEW
- James Whitmore's PEP status needs to be confirmed. As a Politically
  Exposed Person, he may be subject to enhanced due diligence to prevent
  money laundering and terrorist financing.
- The origin of James Whitmore's crypto funds is unclear. Although exchange
  records are present, we need to establish where these funds came from to
  ensure compliance with FINTRAC guidelines.

WHERE TO FOCUS
- Verify James Whitmore's PEP status through official channels and conduct
  enhanced due diligence as required.
- Obtain documentation or clarification on the origin of James Whitmore's
  crypto funds to ensure compliance with FINTRAC guidelines.

The summary tells the bank what has already been verified, what still needs attention, and where the compliance officer should focus. For James, those areas are his PEP status and the source of his crypto funds.

At first glance, it looks like the agent trace captured everything.

But the model risk team is not looking at what the agents decided. What they want to know is what produced each decision, and whether the bank can recreate it months or even years later.

That means answering questions like:

• Which version of the AI model generated the summary? 
• Which prompt version was active? 
• Which documents and external data sources were used? 
• Which API responses contributed to the decision?

LangSmith does not capture all of that because much of it lives in external systems.

Now imagine if each of the agents above also used an AI model instead of following fixed rules.

The identity agent might use one model, the screening agent another, and the wealth agent a third.

Each would run on a different model version, follow its own prompt, and call a different set of external services.

Every one of those inputs needs to be recorded with its version.

The reason for doing that is simple.

If a regulator asks six months later how James was onboarded, the bank must be able to reproduce that decision using the exact models, prompts, documents, and data sources that were active at the time. 

That is what the model risk team needs before they approve the system to go live.

Now you know why the review team rejected the agent.

It wasn’t because the AI made the wrong decision. The tests passed. The pilot was successful. The agent worked exactly as expected.

The problem was that the bank couldn’t fully explain how those decisions were produced. The agent recorded what it decided, but it didn’t capture everything the model risk team needed to recreate those decisions months or even years later.

That’s the difference between building an AI agent and deploying one inside a bank.

An engineering trace helps developers understand how the system ran. A regulatory record helps the bank explain every decision to a regulator using the exact models, prompts, documents, and data sources that were active at the time.

Until both records exist, the Model Risk team has only one answer.

The agent works. But it still can’t go live.