{"id":198868,"date":"2026-07-14T05:39:42","date_gmt":"2026-07-14T09:39:42","guid":{"rendered":"https:\/\/innowise.com\/?page_id=198868"},"modified":"2026-07-20T07:23:32","modified_gmt":"2026-07-20T11:23:32","slug":"ai-agent-architecture-in-banking","status":"publish","type":"page","link":"https:\/\/innowise.com\/es\/expert-tips\/ai-agent-architecture-in-banking\/","title":{"rendered":"Agentes de IA en el sector bancario: la arquitectura de confianza de cuatro capas que garantiza una implementaci\u00f3n segura"},"content":{"rendered":"\t\t
\n\t\t\t\t
\n\t\t\t\t\t
\n\t\t
\n\t\t\t\t\t
\n\t\t
\n\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

AI agents in banking: the 4-layer trust architecture behind safe deployment<\/h1>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t
\n\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Apr 29, 2026<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

10<\/span>\u00a0min read<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"Illustration\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t
[summarize_button_ai title=\"Summarize with AI\"]<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Off-the-shelf agent frameworks are insufficient for banking. Yes, that\u2019s the point I\u2019d start with, and no, a cleaner prompt strategy or a stricter API gateway doesn\u2019t change it.<\/span><\/p>

A standard stack with LangChain, tools, vector DB, and an API gateway can make an agent functional. It can route an intent, fetch context, call a tool, and return a polished answer. Fine. But banking doesn\u2019t fail at the \u201ccan it call the API?\u201d level. <\/span>Banking fails at the \u201cwas this call allowed, scoped, verified, logged, and safe to show to this customer?\u201d level.<\/b> That\u2019s a different architecture problem.<\/span><\/p>

There are three reasons I wouldn\u2019t put a generic agent stack near production banking workflows without adding a dedicated trust layer.<\/span><\/p>

First, financial data is liability data.<\/b> A hallucinated answer in a retail chatbot is embarrassing. A hallucinated balance, transaction status, fee explanation, or credit decision can become legal exposure. Under the <\/span>FCA Consumer Duty<\/span><\/a>, for example, the institution has to show that customers receive fair, understandable, and appropriate support. If the model invents a repayment option or explains a product incorrectly, you can\u2019t shrug and blame \u201cthe AI.\u201d The bank owns the output. So the architecture has to treat every factual claim as something to verify against a source system.<\/span><\/p>

Second, multi-tenancy is not just a product design choice.<\/b> If you serve several banking clients, merchants, business units, or regions from one platform, tenant isolation has to exist at every layer: prompts, memory, vector indexes, tool permissions, logs, Redis keys, database rows, secrets, and audit exports. One cross-tenant leak is not a bug ticket. It can be a reportable incident. This is why I don\u2019t like architectures where the agent has broad access and the app layer \u201cremembers\u201d to filter things later. Filtering later is how data leaks happen.<\/span><\/p>

Third, the LLM is the least trustworthy component in the chain.<\/b> That sounds harsh, but it\u2019s the right assumption. The model is probabilistic. It can follow malicious instructions, over-trust retrieved context, or expose PII in a summary. It can produce a tool call that looks valid until you inspect the parameters. So I would never let the model sit directly next to core banking APIs.<\/span><\/p>

The safer pattern is to let the model reason, but keep enforcement in deterministic systems. Reasoning belongs in the agent layer. Enforcement belongs in schema validators, policy checks, tenant-scoped permissions, approval gates, and audit logs. Once you make that split, the architecture stops being a chain of model-driven API calls and becomes a controlled trust system, with the LLM treated as a useful but unreliable reasoning component.<\/span><\/p>

One framing makes that split easier to apply. When I look at a banking agent, the question I care about is how much authority it holds and how far that authority has to travel from the human who granted it. Capability tells you how good the demo is. Authority determines how much control the system is allowed to exercise. A brilliant model wired to read-only tools is a thin assistant. A dull model holding a standing key that can move funds is a different problem, and it needs every layer below. I split that authority axis into four classes \u2014 assistant, orchestrator, operator, and economic actor \u2014 in the article <\/span>Not every agent is an economic actor<\/i><\/b><\/a>.<\/span><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

\n\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t
Andrew Nalichaev<\/a><\/div>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Blockchain Expert & DeFi Analyst<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t<\/a>\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Andrew translates decentralized concepts into secure, functional financial tools. He navigates the volatile DeFi landscape to build scalable blockchain infrastructures that address real-world utility, moving past the buzzwords to deliver technical value.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

View profile<\/a><\/h4>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

The 4-layer trust model for banking AI agents<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t
\n\t\t
\n\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

For banking, a four-layer trust model makes the architecture easier to control, audit, and defend. It forces one uncomfortable question at every step: what should this part of the stack be allowed to know, decide, and touch?\u00a0<\/span><\/p>

A banking agent can talk like one product, but it should not run like one flat system. The client should not know the banking core. The agent should not call financial APIs directly. The gateway should not improvise. Core banking should not trust model-generated requests just because they came from an approved channel.\u00a0<\/span><\/p>

Here\u2019s the path I\u2019d expect to see in a production-grade setup: <\/span><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"AI\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

The enforced path is simple:<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"Banking\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

These four layers should be <\/span>enforceable boundaries between trust zones<\/b>. If the agent needs account data, it goes through the gateway. If it prepares a payment, it goes through the gateway. If it needs an external KYC, AML, card, or fraud provider, the request still moves through core banking first.<\/span><\/p>

With that control path in mind, let\u2019s go layer by layer and look at what each part should own, what it should never touch, and where the handoff needs a real check. <\/span><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

<\/span><\/span>Layer 1: Client layer<\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

The client layer is where the user meets the agent, but it should stay thin. Mobile apps, web apps, chat widgets, voice interfaces, and messengers should not carry banking logic. Their job is to capture the request, pass identity and session context, render the response, and hand off anything sensitive to the layers below. <\/span><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t
\r\n
\r\n
\r\n
\r\n
Client surface<\/div>\r\n
Typical stack<\/div>\r\n
What it should own<\/div>\r\n <\/div>\r\n\r\n
\r\n
Mobile app<\/div>\r\n
React Native<\/div>\r\n
User interaction, device context, push notifications<\/div>\r\n <\/div>\r\n \r\n
\r\n
Web app<\/div>\r\n
React<\/div>\r\n
Authenticated banking sessions, UI state, response rendering<\/div>\r\n <\/div>\r\n \r\n
\r\n
Chat widget<\/div>\r\n
Web SDK<\/div>\r\n
Embedded support flows, merchant portals, customer service entry points<\/div>\r\n <\/div>\r\n \r\n
\r\n
Messengers<\/div>\r\n
WhatsApp, Telegram, iMessage<\/div>\r\n
Channel-specific formatting and delivery<\/div>\r\n <\/div>\r\n \r\n
\r\n
Voice<\/div>\r\n
WebSocket<\/div>\r\n
Real-time speech sessions and interruption handling<\/div>\r\n <\/div>\r\n \r\n
\r\n
External agents<\/div>\r\n
MCP<\/div>\r\n
Controlled agent-to-agent or agent-to-system entry points<\/div>\r\n <\/div>\r\n <\/div> \r\n <\/div>\r\n<\/div>\r\n\r\n