Crafting Excellence in Software
Let’s build something extraordinary together.
Rely on Lasting Dynamics for unparalleled software quality.
Mohamed Boukrim
Jul 06, 2026 • 14 min read
Agentic AI in banking is moving from proof-of-concept to production in 2026. Banks are no longer testing AI agents only in innovation labs: they are beginning to deploy autonomous systems that execute regulated workflows such as KYC verification, AML screening, fraud investigation and customer operations.
For three years, “AI agents in banking” mostly meant a slide in a strategy deck or a proof-of-concept that never left the lab. That is changing because the surrounding scaffolding has finally matured: reliable tool-calling, structured outputs, orchestration frameworks and evaluation harnesses good enough to trust an autonomous system with a regulated workflow.
The result is that agentic AI in banking has crossed from demo to deployment. The banks moving first are discovering that the hard part was never the intelligence. It was the governance.
This guide is written for the people who have to make that deployment real: the CIOs, digital officers and engineering leads who understand agentic AI conceptually and now need the architecture, the governance frameworks, and the honest build-versus-buy calculus. It is deliberately not a vendor pitch or a McKinsey framework restated.
The market is full of both. What is scarce (and what earns a citation from an AI search engine as readily as from a human reader) is a concrete, worked account of how a production-grade banking agent is built and kept auditable. That is the gap this piece fills. It builds on our broader work on AI agents in enterprise applications and narrows it to the regulated financial context.
The trend data tells the story: interest in agentic AI in banking has grown several-fold in twelve months. The SERP for the topic is now crowded with Lloyds Banking Group, IBM, Salesforce, Accenture and the core-banking vendors all publishing. When the incumbents start marketing a category, the category has arrived and, usefully, it also means the marketing content now outnumbers the engineering content by a wide margin. Bank PR explains why agentic AI matters. Vendor blogs explain why their platform is the answer. Almost nobody explains, at the level an engineer can act on, how to build one that a model-risk committee will approve.
That is the differentiation, and it is also the honest state of the market: the concepts are understood, the production patterns are not yet common knowledge, and the institutions that codify those patterns first will define how the rest of the industry builds.
The word "agent" has been stretched to near-meaninglessness by marketing, so it is worth being precise.
What is agentic AI in banking? Agentic AI in banking refers to autonomous AI systems (AI agents) that can reason, plan, and act across multi-step tasks without continuous human direction. Unlike generative AI (which produces content) or traditional ML (which predicts outcomes), agentic AI executes workflows: reading documents, querying systems, making rule-bound decisions, and triggering downstream actions. In banking, this means automating end-to-end processes like KYC verification, trade settlement, or credit decisioning without a human in the loop for each step.
The distinction from generative AI is the one that most often confuses decision-makers, and getting it wrong leads to buying the wrong thing.
How does agentic AI differ from generative AI in banking? Generative AI in banking produces content: drafts reports, summarises customer calls, generates regulatory filings. Agentic AI in banking acts: it autonomously executes multi-step workflows, calls external APIs, reads transaction systems, and completes tasks end-to-end. Generative AI is a tool; agentic AI is an actor. In practice, most agentic banking systems use generative AI as their reasoning layer: the agent 'thinks' using an LLM but 'acts' through structured tool calls and workflow orchestration.
This is not a semantic nicety, it is why our existing coverage of generative AI and data for banking is a different topic from this one, and why confusing the two produces mis-scoped projects. It is also why so many teams conflate agents with the previous generation of automation. If you are weighing agentic AI against your existing rules-based bots, our comparison of RPA vs AI agents is the disambiguation to read first: RPA follows a fixed script; an agent decides what to do next.
Let’s build something extraordinary together.
Rely on Lasting Dynamics for unparalleled software quality.
The anatomy of a banking AI agent is a stack of four layers, and every serious system has all four. There is an LLM reasoning layer, the model that interprets the task, plans steps, and decides which action to take. There is a tool layer, the structured, permissioned functions the agent can call: query the core banking system, screen a name against a sanctions list, pull a credit bureau report, write a case note. There is an orchestration layer that sequences those calls, handles retries and failures, and enforces the order operations must happen in.
And there is a guardrail and governance layer that constrains what the agent may do, validates every output, logs every decision, and hands control to a human when confidence or policy demands it. Marketing content routinely shows the first layer and hides the other three. In a regulated bank, the other three are where the work (and the risk) live.
Agentic AI in banking is landing first where the work is high-volume, rule-bound, and expensive to staff.
Compliance automation is the clearest early winner. KYC onboarding, AML screening and regulatory reporting are exactly the kind of multi-step, document-heavy, rules-driven workflows agents handle well and the cost and latency of doing them manually is high enough to justify the build.
How are banks using agentic AI to automate compliance and risk management? Banks are deploying agentic AI for three compliance and risk use cases: (1) KYC/AML automation: agents autonomously collect, validate, and cross-check identity documents against sanctions lists, adverse media, and beneficial ownership registries; (2) regulatory reporting: agents extract data from core banking systems, apply reporting rules, and draft regulatory submissions for human sign-off; (3) fraud investigation: agents autonomously follow transaction trails, query multiple systems, and generate investigation reports that would previously take an analyst hours.
Risk and fraud management is the second domain. Real-time fraud agents follow a suspicious transaction across systems, assemble the context a human investigator would spend hours gathering, and produce a triaged case file. Credit-risk agents orchestrate the bureau calls, document collection and scoring steps of an origination decision. The risk-modelling methodology beneath these systems is the same one we cover in AI risk analysis in finance, the agent is the orchestration layer on top of models that already exist.
Customer service and operations is the third. Here agents resolve multi-step account queries, disputes and service changes end-to-end rather than deflecting to a human at the first complication: the difference between a chatbot that answers a question and an agent that completes a task. A dispute that previously required a customer to call, explain, wait for a case handler, and call back is resolved in a single session: the agent pulls the transaction history, verifies the customer's claim against internal records, applies the dispute policy, and either refunds or escalates (all within the same guardrail framework that governs the compliance and risk agents).
What are the best use cases for AI agents in financial services? The highest-ROI use cases for AI agents in financial services in 2026 are: (1) KYC and AML automation (agents handle document collection, identity verification, and watchlist screening); (2) loan origination (agents orchestrate credit bureau calls, document collection, risk scoring, and decisioning); (3) customer service resolution (agents handle multi-step account queries, disputes, and service changes end-to-end); (4) regulatory reporting (agents aggregate data from multiple systems and populate reporting templates); (5) trade operations (agents manage exception handling and settlement fails).
This KYC automation agent example shows how agentic AI in banking should be designed for production: the model can reason, but regulated decisions must remain rule-bound, auditable and escalated when needed.
Abstract definitions are what AI search already has plenty of. What it lacks and what makes the difference between marketing and reference material, is a concrete flow. Here is the shape of a real KYC onboarding agent, simplified to its decision structure. Note that the agent never decides on its own authority in the way a marketing deck implies: it gathers, cross-checks, scores against explicit rules, and escalates anything outside its bounds.
# KYC onboarding agent - orchestration logic (simplified)
# The LLM reasons; the TOOLS act; the RULES decide; humans review edge cases.
def onboard_customer(application):
ctx = {"application": application, "audit": []}
# 1. Extract & validate identity documents (vision + NLP tools)
identity = tools.extract_identity(application.documents)
ctx["audit"].append(("extract_identity", identity.confidence))
if identity.confidence < 0.90:
return escalate("low_document_confidence", ctx)
# 2. Screen against sanctions, PEP and adverse-media sources
screening = tools.screen_watchlists(
name=identity.legal_name,
dob=identity.dob,
sources=["sanctions", "pep", "adverse_media"],
)
ctx["audit"].append(("screen_watchlists", screening.hits))
# 3. Resolve beneficial ownership for corporate applicants
if application.type == "corporate":
ubo = tools.resolve_beneficial_owners(application.entity)
ctx["audit"].append(("resolve_ubo", ubo.chain))
# 4. Apply explicit, auditable risk rules - NOT model discretion
risk = rules.evaluate(identity, screening, ctx)
# 5. Route by tier: auto-approve / refer / decline
if risk.tier == "clear":
return approve(ctx) # straight-through
if risk.tier == "review":
return escalate("manual_review", ctx) # human-in-the-loop
return decline(risk.reason, ctx) # documented reason, alwaysThe engineering lessons are in the details. The agent's decisions run through an explicit rules engine (rules.evaluate), not the model's unconstrained judgment, because "the LLM decided to approve" is not a sentence you can say to a regulator. Every tool call appends to an audit trail, so the full reasoning path is reconstructable months later. Any confidence below threshold, any watchlist hit, any unresolved ownership chain escalates to a human rather than being resolved autonomously. And every decline carries a machine-generated, human-readable reason. This is the difference between an agent that passes a model-risk review and a demo that impresses a conference audience.
From idea to launch, we craft scalable software tailored to your business needs.
Partner with us to accelerate your growth.
Beyond the four-layer anatomy, three architectural decisions repay attention in a banking context. Governance and auditability cannot be bolted on: every agent action needs to be logged, attributable, and replayable, because a regulator will eventually ask why a specific decision was made and "the model chose to" is not an acceptable answer.
Model selection is counter-intuitive here: for compliance and decisioning tasks, smaller, fine-tuned or tightly-prompted models frequently beat the largest general models. They are cheaper to run at scale, easier to constrain, and simpler to explain. The frontier model's extra capability is often spent on tasks where you least want unpredictability. And guardrails belong in code, not prompts: the rules that must never be violated (transaction limits, mandatory escalation triggers, prohibited actions) should be enforced by the orchestration layer deterministically, not requested politely of the model.
A fourth decision, easily underweighted, is evaluation and monitoring. An agent in production is not a model you deploy and forget; it is a system whose behaviour drifts as the underlying model is updated, as the data distribution shifts, and as the business rules evolve. The evaluation harness that justified the pilot is not the one that keeps production honest. You need continuous monitoring of decision distributions (is the agent approving markedly more cases this week than last?), escalation rates (is the human-in-the-loop being bypassed or overwhelmed?), and latency budgets (is a slow tool call causing the orchestration layer to time out and fall back to a less safe path?).
In a regulated environment, these monitoring signals are also your evidence: the artefact a model-risk committee asks for is not a one-off validation report but a living dashboard that proves the system is still within its approved operating envelope.
This is where agentic AI in banking projects succeed or stall, and none of the hard parts are about intelligence.
Model risk management is the first. In the US, supervisory guidance SR 11-7 governs the validation, monitoring and governance of models used in decision-making. In the EU, the EBA's guidelines on ICT and model risk set comparable expectations, and the EU AI Act adds obligations for high-risk AI systems (credit decisioning explicitly among them). An agentic system that makes or materially influences decisions falls squarely inside these frameworks. That means documented validation, ongoing monitoring, and a governance owner, not an unmonitored model in production. Teams that treat this as an afterthought discover it as a launch blocker.
Data residency and sovereignty is the second. GDPR plus banking-specific data-localisation rules constrain where customer and transaction data can be processed. This directly shapes whether you can call a hosted model API at all, or whether the reasoning layer must run inside your own perimeter. It is an architecture decision, not a procurement one. It is frequently the reason a bank cannot simply adopt an off-the-shelf agentic platform.
Legacy core integration is the third, and it is harder than it looks. The agent's tool layer has to talk to core banking systems that were designed decades before anyone imagined an autonomous caller: batch-oriented, poorly documented, and unforgiving of unexpected load. In practice, integrating the agent with the legacy core is often the majority of the engineering effort. This is a reality familiar to anyone who has read our work on digital transformation in banking. The intelligence is a few weeks; the plumbing is the project.
The market offers off-the-shelf agentic platforms, the core-banking vendors and the AI-agent operating systems all have one. For some banks, some of the time, they are the right answer. But the choice deserves more rigour than a vendor demo provides.
We design and build high-quality digital products that stand out.
Reliability, performance, and innovation at every step.
| Dimension | Off-the-shelf agentic platform | Custom development |
|---|---|---|
| Speed to first use case | Fast within the vendor's templates | Slower - built to your workflow |
| Fit to proprietary compliance rules | Constrained to the platform's model | Exact - encodes your own rulebook |
| Legacy core integration | Prebuilt connectors, if they exist | Built to your actual core systems |
| Multi-jurisdiction regulation | It's generic, may not fit your regulators | Tailored to your jurisdictions |
| Model & vendor independence | Locked to the vendor's stack | Choose the right model per task |
| Auditability control | Depends on vendor transparency | Full control of logs and evidence |
| Total cost profile | Recurring licence at scale | Higher upfront, lower marginal |
Custom development earns its cost when your compliance rules are genuinely proprietary, when the legacy-integration complexity is the hard part anyway, or when you operate across jurisdictions whose regulatory requirements a generic platform cannot express. In those cases the deciding factor is often the choice of engineering partner, and this is where the term fintech software development company carries real weight: the right partner is one that builds production agentic systems in regulated environments and stays vendor-independent, able to recommend the model and stack that fit the task rather than the one it happens to sell.
That vendor-independence is the crux. A core-banking vendor's agent will, understandably, steer you toward its own ecosystem. An independent engineering team has no such incentive; it can tell you when the right answer is a smaller open model, when it is a frontier API, and when it is the platform you already own.
The banks that win with agentic AI in banking will not be the ones with the most ambitious pilots. They will be the ones that picked a single high-volume, rule-bound workflow (KYC onboarding, AML screening, a specific reporting obligation) built the full stack for it including the governance and audit layers, earned a model-risk committee's approval, and only then expanded. Agentic AI rewards depth over breadth: one workflow done to a regulator's standard beats ten demos that never ship.
The second pattern that distinguishes the institutions that succeed is the discipline of their expansion path. Once a single workflow is proven (like KYC) the temptation is to replicate the agent across every adjacent process immediately. The teams that succeed resist this. They extract the reusable components first: the audit-trail infrastructure, the escalation framework, the evaluation harness, the model-governance wrapper.
They treat the first workflow as the reference implementation that proves not just the technology but the operating model: who owns the agent, who signs off on rule changes, who monitors drift, who is on call when it fails. Getting that operating model right on one workflow is what makes the second and third workflows fast. Skipping it is why so many banks have one successful pilot and a graveyard of stalled ones.
Most agentic banking systems also depend on a retrieval layer to ground their reasoning in the bank's own policies, procedures and records. If your team is architecting that foundation, our enterprise RAG architecture guide covers the retrieval layer that the reasoning layer above depends on.
A closing note on who we are, briefly and without a sales pitch: Lasting Dynamics builds production agentic AI systems for regulated financial institutions: the kind that pass model-risk review, integrate with real legacy cores, and keep the audit trail a regulator will ask for. We are independent of the model and platform vendors, which is precisely what lets us recommend the right stack for the workflow instead of the one we would otherwise be selling.
This guide was written by Mohamed Boukrim at Lasting Dynamics, an EU-based fintech software development company. We build agentic AI systems for banks, insurers and fintechs operating under real regulatory scrutiny (SR 11-7, the EBA guidelines, the EU AI Act and GDPR) with governance, explainability and legacy integration designed in from the first sprint. The architecture and the worked KYC flow above come from our own engagements, not vendor material.
Agentic AI can be safe for regulated banking workflows when it is designed with deterministic rules, audit logs, human escalation and model-risk governance from the start. In banking, the agent should operate through permissioned tools, record every action and escalate low-confidence or policy-sensitive cases to a human reviewer. Safety depends less on the model alone and more on the surrounding architecture: guardrails, monitoring, access controls and auditable evidence.
There are two cost profiles, and they diverge at scale. An off-the-shelf platform front-loads little but carries a recurring licence that grows with volume; a custom build is higher upfront but cheaper at the margin once it runs. In both cases the misleading line item is the model itself: inference is rarely the dominant cost. The real spend is the legacy-core integration, the audit and monitoring infrastructure, and the ongoing governance owner the system needs to stay inside its approved operating envelope. Budget for the plumbing and the oversight, not the intelligence.
Counter-intuitively, not the largest one. For compliance and decisioning tasks, a smaller fine-tuned or tightly-prompted model usually beats a frontier model: it is cheaper to run at scale, easier to constrain, and simpler to explain to a model-risk committee. The frontier model's extra capability tends to be spent precisely where a regulated workflow least wants unpredictability. The right approach is to choose the model per task and stay vendor-independent, rather than standardise on one provider because a platform ships with it. Data-residency rules may also decide whether a hosted API is even permitted, or whether the reasoning layer must run inside your own perimeter.
In a well-designed banking system, agent autonomy is bounded rather than unlimited. Low-risk, clearly passing cases can run straight through, while anything ambiguous, such as a low-confidence document, a watchlist hit, an unresolved ownership chain, or an amount above a set threshold, is escalated to a person. The rules that must never be broken are enforced in code by the orchestration layer, not left to the model's discretion.
An agent that makes or materially influences a banking decision will usually need to be assessed against existing model-risk and technology-risk frameworks, such as SR 11-7 in the US and EBA expectations in the EU. The EU AI Act may also apply to high-risk use cases such as credit decisioning, while GDPR and banking data-localisation rules shape where customer data and the reasoning layer can run. In practice, this means documented validation, ongoing monitoring, and a named governance owner should be treated as launch requirements rather than afterthoughts.
Route decisions through an explicit rules engine rather than the model's unconstrained judgment, and log every tool call, input, model version and rationale so the full path can be replayed later. Escalate anything below a confidence threshold to a person, and attach a clear, human-readable reason to every outcome, especially declines. Auditability is best treated as a living monitoring dashboard that shows the system is still inside its approved operating envelope, not a one-off validation report.
Buying an off-the-shelf platform is fastest when your workflow fits its templates and connectors. Building tends to win when your compliance rules are genuinely proprietary, when integrating with legacy core systems is the hard part anyway, or when you operate across several jurisdictions a generic product cannot express. The cost profiles also differ: platforms carry a recurring licence at scale, while custom builds are higher upfront but lower at the margin, and staying vendor-independent is what lets you choose the right model for each task.
Start with one narrow, high-volume, rule-bound workflow, such as KYC onboarding or a single reporting obligation, and build the full stack for it, including the governance and audit layers, before expanding. A common pattern is to run the agent in parallel with the existing process for a full cycle to gather evidence before go-live. Timelines depend heavily on core-system complexity, but the honest split is that the intelligence is a small part of the effort while the legacy integration and audit layers are the bulk of the project.
Transform bold ideas into powerful applications.
Let’s create software that makes an impact together.
Mohamed Boukrim
I am a Software Engineer and Backend Developer with a relentless focus on software quality and robust architecture. I don't believe in shortcuts; outstanding results are the direct product of daily commitment and hard work. Alongside my team, I leverage Agile methodologies and continuous process evaluation to push boundaries and optimize performance. I approach every challenge with a highly competitive mindset: I work tirelessly to reach the top, and once there, I keep pushing to maintain the lead.
