How Agentic AI Actually Works in Banking (A Step-by-Step Guide)

How agentic AI works in banking step-by-step guide

I built a working prototype in Python to go alongside this article series. It includes the full onboarding system, the LangSmith agent traces, and the case records used in this post. You can find the full code on GitHub.

Most articles explain agentic AI as a technology topic, but very few explain what happens when you apply that technology inside a bank.

Banking is a heavily regulated industry because every decision can have serious consequences for both the customer and the bank. That’s why every decision an AI agent makes needs a complete paper trail.

Months or even years later, a regulator can walk into the bank and ask, “Explain exactly how this decision was made.”

The bank has to be able to answer that question.

Let’s see how that works using one real example.

Meet James

James sold his software company last year for $18 million. He now wants to open a bank account in Canada and transfer $5 million into it. Four million comes from the sale of his business, while the remaining $1 million comes from crypto holdings.

From James’s point of view, everything seems straightforward. He has the money, the documents to back it up, and he’s bringing millions of dollars to the bank.

Yet the bank still can’t open the account.

Why?

Because before the bank can accept James as a client, it has to answer a series of questions.

Did James really sell his software company?

Can the bank trace the $4 million back to that sale?

Can James show where the remaining $1 million in crypto came from?

Has he been screened against sanctions, politically exposed person lists, and adverse media?

A single AI model can answer none of those questions.

Instead, the bank breaks the work into smaller tasks. Each task is handled by a specialist AI agent responsible for one part of the onboarding process.

Together, those agents complete most of the routine checks before the compliance officer even opens James’s file. By the time she reviews the application, the routine checks are already done. She only needs to focus on what requires human judgment.

Here’s the complete system

James’s application enters the system.

The orchestrator reads everything James has submitted and decides which specialist agents need to run. Four specialist agents then work at the same time, each checking one part of James’s application.

Their findings go to the risk engine. It applies the bank’s risk rules, assigns James’s risk level, and highlights the areas that need the compliance officer’s attention.

That output is then sent to an AI model. It turns the findings into a plain English summary for the compliance officer to review.

Every step is recorded so that the bank can trace every decision later.

Let’s look at how each part works, starting with the orchestrator.

Think about a good project manager.

A good project manager doesn’t assign every team member to every project. She first understands the work that needs to be done, then decides who should be involved.

The orchestrator does the same thing for James’s application.

It receives the application, reads through everything James submitted, and builds a plan. That plan answers three questions.

Which agents should run?

What information does each agent need?

And in what order should everything happen?

For James, the orchestrator sees a business sale, crypto holdings, and a declared PEP status (PEP stands for Politically Exposed Person, which usually requires additional regulatory checks). Based on that, it decides that all four specialist agents need to run.

It also decides what information each agent receives. Identity documents go to the identity verification agent. Screening information goes to the screening agent. Financial records go to the wealth and funds agent. Business records go to the business review agent.

In the prototype, LangGraph manages that orchestration.

Once everything is in place, the specialist agents begin their work.

Each agent has one job

One verifies James’s identity. Another screens him against sanctions and PEP databases. A third reviews his wealth and source of funds. The last reviews the business he sold.

Because these checks don’t depend on each other, all four agents run at the same time. They don’t wait for one another to finish, which is one of the biggest reasons the onboarding process becomes much faster.

These agents follow a fixed set of rules rather than using an AI model. The same input always produces the same output. That’s a deliberate design choice, and you’ll see why when we get to the risk engine.

Now let’s see what each of those specialist agents does.

The Identity Verification agent

The Identity Verification agent starts with a simple question.

Is James really who he says he is?

To answer that, the bank verifies James’s identity using government-issued documents such as a passport or driver’s licence. The agent checks that the required documents are present and that the information matches the application. In a real bank, it would also connect to external identity verification providers, such as Equifax or TransUnion.

In James’s case, everything checks out and the finding comes back as IDENTITY_VERIFIED.

The Screening agent

The Screening agent checks James against sanctions lists, politically exposed person databases, and adverse media sources. In a real bank, these checks are typically performed using commercial screening providers such as World-Check, Dow Jones, or ComplyAdvantage.

James declared that he might be a politically exposed person. The screening confirms that declaration, and the finding comes back as PEP_CONFIRMED.

The Wealth and Funds agent

The Wealth and Funds agent focuses on the $1 million James plans to transfer from his crypto holdings. It confirms that the exchange account belongs to James and looks for evidence showing where those crypto assets came from.

James can prove he owns the exchange account, but he hasn’t provided enough evidence showing where the crypto originally came from. So the agent flags that part of the review for additional attention. The finding comes back as WEALTH_SUPPORTED_CRYPTO_PRESENT.

The Business Review agent

The Business Review agent reviews the software company James sold. It confirms that James was connected to the company and verifies the sale using the supporting documents and corporate registry. Everything lines up, and the finding comes back as BUSINESS_SALE_SUPPORTED.

The Risk Engine

Each agent has now returned its finding. Those findings flow into the risk engine.

The risk engine applies the bank’s internal risk rules to everything the specialist agents found.

For James, two things stand out. His PEP status has been confirmed, and the source of his crypto funds remains unestablished. Taken together, those conditions classify James as a HIGH RISK client. The risk engine also tells the compliance officer what has already been verified and what still needs attention, so she knows exactly where to focus.

This entire step is rules-based rather than AI-based, and so are the specialist agents we saw earlier.

The reason is the same for both. A regulator can ask why James was classified as HIGH RISK, and the bank must provide the same explanation every time. Rules guarantee that consistency because the same input always produces the same output. But AI models are probabilistic, so they don’t.

So where does AI actually come in?

The risk engine produces a structured output that is easy for machines to read but not easy for a compliance officer to review quickly. An AI model takes that output and turns it into a plain English summary highlighting what has been verified and what still needs attention.

The summary never says “approve” or “reject”. The AI prepares the case, and the compliance officer makes the decision.

Even though James’s case is complex, the compliance officer doesn’t have to review everything from scratch. The routine checks are already done. She focuses on the two areas the risk engine flagged, reviews the supporting evidence, and makes her call. Approve, reject, request more information, or escalate to senior management.

Every step in this process is recorded. The bank can see which agents ran, what they found, how the risk engine reached its decision, and why the case was classified that way. In the prototype, LangSmith captures that complete trace.

So that’s how agentic AI works in banking

You started this article wondering why you need to read another article on agentic AI.

Now you know. Building agentic AI for a bank is different from building it for a technology company. Every decision needs a paper trail. A regulator can ask about any of those decisions at any time. And a human always needs to review what the AI has done before the bank acts on it.

James’s case shows how all of that works in practice. The orchestrator decides which agents to run. The agents check identity, sanctions, wealth, and business history at the same time. The risk engine applies the bank’s own risk rules and shows the compliance officer exactly where to focus. The AI model writes a summary in plain English. And every step along the way gets traced, recorded, and stored so the bank can explain the decision later.

That’s what agentic AI looks like when you build it for banking.