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 and politically exposed person lists?
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 works out what needs to happen.
The orchestrator does three things.
First, it decides which agents should run.
The identity, screening and wealth agents run for every client, because a bank has to perform those checks on everyone it onboards.
The fourth check is the one that varies.
Some of James’s declared wealth comes from his business, so the orchestrator includes the business review agent. A client whose wealth comes only from a salary wouldn’t need it, and that agent would never run.
Second, it decides what information each agent needs.
The identity agent gets his name, nationality, residency and government ID. The screening agent gets his name, date of birth, and declaration that he may be a politically exposed person. The wealth agent gets his personal source of wealth, personal source of funds, and the supporting documents. The business agent gets the company details and supporting business documents.
Finally, it records why each agent is running.
In a bank, every check exists because a regulation requires it. That regulation shaped the check in the first place, and it’s what a compliance officer relies on when reviewing the case. So the orchestrator writes the regulatory requirement next to each instruction it gives to the individual agents.
So that months later, when a regulator asks why the screening agent ran on James, the reason is recorded in the trace alongside what the agent found.
In the prototype, LangGraph manages this orchestration. It takes the plan the orchestrator produced, runs the agents, and carries their findings forward to the next step.
Once that 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?
A bank answers that by verifying his government-issued documents, such as a passport or driver’s licence, against external sources like Equifax or TransUnion.
We’ve kept it simpler in the prototype. The agent checks that his name, nationality and residency have been declared, and that a government ID has been uploaded. For James, all four are present, so the finding comes back as IDENTITY_VERIFIED.
The Screening agent
The Screening agent checks James against sanctions lists and politically exposed person registries.
A bank runs those checks through commercial providers such as World-Check, Dow Jones or ComplyAdvantage, which maintain the lists and keep them current.
In the prototype the lists live inside the agent itself. It matches James on name and date of birth, finds him in the PEP registry, and confirms he declared that status himself. The finding comes back as PEP_CONFIRMED.
The Wealth and Funds agent
The Wealth and Funds agent looks only at James’s personal money. Anything connected to his company goes to a different agent.
The agent answers two questions.
Where did this wealth come from? For James, it comes from his cryptocurrency holdings held through an exchange.
How is the money arriving? It is a one-million-dollar transfer from the same exchange account.
In a real bank, the second question would typically be investigated using a blockchain analytics tool such as Chainalysis. This helps determine the origin of the cryptocurrency before the funds are accepted.
The prototype performs a much simpler check. It verifies that James’s wealth documents, bank statements, and cryptocurrency exchange records have been provided. Since these documents are available, the agent returns the finding WEALTH_SUPPORTED_CRYPTO_PRESENT.
This finding does not mean that the cryptocurrency has been verified as legitimate. Instead, it indicates that cryptocurrency is involved and that the prototype cannot verify its origin. As a result, the case is referred to the compliance officer, with this limitation clearly identified.
The Business Review agent
The Business Review agent handles the other half of James’s wealth—the portion that came from selling his company.
To verify this, it answers three questions.
- Did James own the company?
- Did the sale take place?
- Does the amount he declared match the recorded sale value?
A bank answers these questions by comparing the sale documents with corporate registry records.
The prototype performs a simplified version of this check. It queries a simulated corporate registry, where James is listed as the founder and CEO of Whitmore Software Inc. It confirms that the sale took place and compares the declared sale value of eighteen million dollars with the registry record. The values match, so the agent returns the finding 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.
In a real bank, the same system would do two things.
It would score the client on factors like where they live, what they do, and what kind of account they want. That score decides the risk level.
But some findings ignore the score entirely. A confirmed sanctions match stops the case, no matter what the score says.
The prototype applies the same kind of rules, but without the scoring. Every decision comes from a rule that either applies or doesn’t, and the scoring model is the part left out because it changes from bank to bank.
For James, two things stand out. His PEP status has been confirmed, and his funds are arriving from a crypto exchange where the origin of the crypto has not been established. Together, those two classify him 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 give the same explanation every time. Rules guarantee that, because the same input always produces the same output. 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.