MCP Gateway for banking AI agents: the control layer between AI and core banking

Jul 3, 2026

10 min read

Summarize with AI

In the previous article, I broke down the four-layer trust architecture for banking AI agents: client layer, agent orchestration, MCP Gateway, and core banking. That model gives you the shape of the system. This article is about the part that makes the shape useful in production.

The MCP Gateway is where agent intent gets tested.

A model can decide that it needs account data, KYC status, payment preparation, AML screening, or a fraud signal. But in banking, “the model decided” is not a control. Before that request moves anywhere near the core, it needs tenant scope, user permissions, schema validation, approval state, audit context, and failure handling. That’s the job of the gateway.

So let’s get into the mechanics: RBAC, schema checks, approval workflows, audit logs, circuit breakers, token scoping, and what this looks like in an underwriting flow.

Andrew Nalichaev

Blockchain Expert & DeFi Analyst

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.

View profile

MCP Gateway as the mandatory chokepoint

I’d judge the MCP Gateway by one thing first: can it reject a request that looks perfectly fine to the agent?

The model may pick the right tool, fill in the expected fields, and produce something that passes basic parsing. From the agent’s side, the call looks ready. From a banking side, it may still be missing the critical parts: tenant access, user role, workflow state, approval threshold, source-system limits, and audit context.

So the gateway has a very specific job. It catches the gap between “the agent produced a valid-looking request” and “the bank is allowed to act on this request.” It doesn’t need to make the model cleverer. It needs to make the model’s actions inspectable, rejectable, and safe to route further.

Here’s how the MCP Gateway handles an agent request:

Behind that decision sit six controls: per-tenant RBAC, schema validation, approval workflows, immutable audit logging, circuit breakers, and token scoping. Each one catches a different class of failure before the request reaches core banking.

RBAC per tenant

Tool and endpoint access by tenant, role, region, and workflow

A payments-only merchant can prepare payouts but cannot call KYC review endpoints

Schema validation

Requests that don’t match approved OpenAPI contracts

A malformed payment payload fails before it reaches the payment service

Approval workflows

Actions that cross risk, amount, beneficiary, or policy thresholds

A high-value transfer goes into an approval queue instead of moving straight to execution

Immutable audit logging

The full request trail: who, what, when, tenant, channel, approval state, and result

Compliance can review a PII-redacted export without reading raw chat transcripts

Circuit breakers

Calls to unhealthy, slow, or rate-limited core services and providers

An AML provider outage triggers fallback messaging instead of repeated failed calls

Token scoping

Overbroad access to tenant data, accounts, or provider tools

A short-lived token can read one account view, not the entire tenant dataset

RBAC is where the gateway starts paying for itself. In a multi-tenant banking platform, access cannot be broad just because the agent is “internal.” Each tenant needs its own permission matrix. A merchant that only uses payment initiation should not receive KYC tools. A support agent in one region should not see card controls for another region. A workflow that only needs balance explanation should not get transfer preparation.

Schema validation is the next filter. The gateway should validate every request against approved OpenAPI specs or equivalent contracts. This catches bad payloads: wrong currency format, missing beneficiary ID, unsupported payment rail, impossible date range, malformed KYC status request. The model can be eloquent and still produce a payload the system should throw away.

Approval workflows are where the non-custodial model becomes concrete. The agent may prepare an action, but high-risk operations need a queue, such as amount thresholds, new beneficiaries, suspicious account state, incomplete KYC, elevated fraud signals, or tenant-specific policies. The gateway should create the approval item, notify the approver, track timeout rules, and return a clear status to the user or operator.

Audit logging has to be designed into the path. For every request, the gateway should write an append-only record. This record should include tenant, user, channel, workflow state, tool, parameters after redaction, validation result, approval state, downstream response, and correlation ID. Compliance teams do not need a beautiful transcript. They need a clean trail that explains why the system allowed or blocked the action.

One distinction worth building in from the start: the log proves what was executed, not who had the standing to make it happen. A trace can perfectly show that a transfer moved from A to B under a given token. It cannot show, on its own, that the action was authorized by a principal both sides recognize, or that the authorization had not already been revoked. In a single-tenant flow that gap is invisible, because the log and the authority records sit in the same place. The moment a dispute crosses a tenant or a counterparty, that gap is the whole problem. So the record should capture standing: which mandate authorized the call, under what scope, and whether it was still valid at that moment. I elaborate on this point in my article A mandate is not governance.

Circuit breakers matter because banking providers fail in boring ways like timeouts, partial outages, slow responses, stale status, and rate limits. The gateway should detect that pattern, retry with backoff when retry is safe, stop repeated calls when it is not, and give the user a useful alternative. “AML provider unavailable, check again later” is better than letting the agent loop, invent a status, or keep hammering a degraded service.

Token scoping limits the blast radius. A tool call should receive the minimum access needed for that specific request, tenant, user, and workflow state. Short-lived, scoped tokens are much safer than long-lived service credentials floating around the agent layer. If something goes wrong, the failed request should have a narrow footprint.

Control AI agent access before it reaches core banking

Innowise helps keep every action permissioned, traceable, and under your control.

Safeguard pipeline: 5 guards for banking AI agents

I already covered the Safeguard Pipeline in the architecture article, but here I want to look at it from a stricter angle: what gets checked before the model starts planning, and what gets checked before the user sees the answer or the system stages an action.The MCP Gateway controls tool access, while the Safeguard Pipeline controls model exposure and model output. They sit close together in the flow, but they catch different failures.

Prompt Injection Detection

Before the agent plans a tool path

The request is blocked, stripped of injected content, or routed to human review

PII Redactor

Before context enters the model

Unneeded sensitive values are masked, tokenized, or removed from the prompt

Llama Guard/safety classifier

Before reasoning continues

The flow is blocked, narrowed to a safe response, or escalated

Hallucination Detection

Before the answer is shown

Unsupported claims are checked against source systems, then corrected, retried, or blocked

Compliance Policy Engine

Before response, staging, or approval

The action is blocked, queued for approval, or rewritten within tenant policy

The timing matters. If prompt injection is detected after the tool call is already prepared, the control is late. If PII redaction runs after the model has seen the raw value, it is only masking the transcript. If hallucination detection happens after the response has been sent, it is just postmortem logging.

So I’d keep the rule simple: input guards run before planning, output guards run before anything leaves the system. The gateway decides whether a tool call can reach core banking. The pipeline decides whether the model had the right input and whether its output is safe enough to show, retry, block, escalate, or send into approval.

The non-custodial model: the agent prepares, never executes

After the MCP Gateway and Safeguard Pipeline, there’s one more rule I’d make explicit in the architecture: the agent should not have custody over the action. In plain English, it shouldn’t be able to move money, execute a trade, approve a payout, or finalize a regulated operation on its own.

That’s what I mean by a non-custodial model. The agent can prepare the next step, but execution stays outside the model. A transfer tool creates a staged transaction awaiting confirmation. An exchange tool returns a quote, fees, expiry time, and a confirmation card. A card tool may prepare a freeze request. A KYC tool may collect missing data and submit it for review. In each case, the agent is preparing the operation, not completing it behind the scenes.

This model changes the regulatory posture of the system. An agent that explains options, gathers context, prepares forms, and stages requests is much easier to defend as a decision-support layer. An agent that executes financial operations autonomously starts looking like an autonomous financial executor, which raises a different set of licensing, liability, audit, and insurance questions.

There’s a cleaner way to say why this rule exists. The moment an agent commits value across an organizational boundary, it stops behaving like an internal orchestrator and starts behaving like an economic actor. That’s the class that carries real liability, and exactly the class you don’t want a probabilistic model occupying on its own. Keeping execution outside the model is how you stop an agent from quietly crossing into it. The class boundary here comes from the fact that not every agent is an economic actor.

That distinction matters when something goes wrong. With a non-custodial setup, you can show what the agent prepared, which gateway checks ran, who or what approved the action, and when core banking executed it. Without that separation, the model sits too close to the money. I wouldn’t design a banking agent that way.

Technology choices and why they matter

I’m adding the stack section for one reason: architecture claims are cheap until you name the tools that make the controls real. It’s easy to say “we isolate tenants,” “we checkpoint workflows,” or “we validate tool calls.” The harder part is choosing a stack where those controls don’t live only in diagrams and good intentions.

In a banking agent system, the stack has to support WebSocket-heavy sessions, typed financial objects, replayable workflows, standard tool access, tenant-aware storage, and runtime isolation. If the tooling fights those requirements, the architecture starts leaking risk in small, boring ways: a missing tenant_id, an untyped tool payload, a workflow state that exists only in chat history, or a connector nobody can audit properly.

So I’d look at the stack through a simple lens: does this choice make the system easier to test, pause, inspect, recover, and defend later? If yes, it belongs in the conversation. If not, it’s probably just developer preference dressed up as architecture.

NestJS over Python

The agent layer handles WebSocket sessions, BFF logic, channel adapters, typed contracts, and financial objects, not just model calls.

TypeScript typing for tenant IDs, balances, beneficiaries, limits, workflow states, and tool payloads.

Keeps client, BFF, and orchestration closer in one stack, with LangChain.js and LangGraph.js available.

LangGraph

Banking workflows branch, pause, resume, and escalate.

Directed workflows, typed state, conditional transitions, and PostgreSQL checkpointing.

Teams can inspect the exact path a KYC, dispute, payment, or underwriting flow took.

MCP

Custom connectors make tool access, permissions, and audit rules harder to govern.

Standard tool discovery, tool descriptions, permissioned calls, and reusable skill interfaces.

Skills like payouts, onboarding, card controls, KYC remediation, and underwriting can expose approved capabilities without direct internal access.

Aurora PostgreSQL + RLS

Tenant isolation should not depend only on tenant_id filters in service code.

Tenant-aware storage for workflows, approvals, audit records, checkpoints, and financial metadata.

RLS, per-tenant Redis, gVisor or Firecracker, and separate secrets vaults reduce cross-tenant leakage risk.

Make AI banking requests traceable and controlled

Innowise helps you set the rules for who can ask, approve, and act

What I’d check before calling a banking agent production-ready

Before I’d call a banking agent deployable, I’d try to break the MCP Gateway on purpose: wrong tenant, wrong role, malformed payload, missing approval, expired token, unavailable provider. The design is ready only if those cases fail cleanly, leave a trace, and don’t require the model to explain what happened.

Here’s the checklist I’d use:

Tenant-scoped RBAC

Every tool and endpoint mapped to tenant, user role, channel, and workflow state

Contract validation

Tool calls checked against approved schemas before execution

Approval routing

Threshold-based queues for payments, new beneficiaries, risky account states, and policy exceptions

Non-custodial execution

Agent prepares actions; user, approver, or policy engine confirms; core banking executes

Audit trail

Append-only logs with tenant, user, channel, tool, redacted parameters, approval state, result, and correlation ID

Provider failure handling

Circuit breakers, retry rules, timeout behavior, and user-facing fallback messages

Token scope

Short-lived tokens limited to the exact tenant, account view, tool, and workflow step

Response and action control

Hallucination checks and policy checks before the answer is shown or the action is staged

That’s where I’d leave the test: can the bank reconstruct, defend, and stop every step of the workflow without relying on the model’s memory or a developer’s explanation? If the MCP Gateway can answer that, the architecture has a real chance outside the demo room.

Contact us

Book a call or fill out the form below and we’ll get back to you once we’ve processed your request.

Name

Company

Phone

Message

Send us a voice message

Attach documents

Upload file

You can attach 1 file up to 2MB. Valid file formats: pdf, jpg, jpeg, png.

By clicking Send, you consent to Innowise processing your personal data per our Privacy Policy to provide you with relevant information. By submitting your phone number, you agree that we may contact you via voice calls, SMS, and messaging apps. Calling, message, and data rates may apply.

You can also send us your request
to contact@innowise.com

What happens next?

Once we’ve received and processed your request, we’ll get back to you to detail your project needs and sign an NDA to ensure confidentiality.

After examining your wants, needs, and expectations, our team will devise a project proposal with the scope of work, team size, time, and cost estimates.

We’ll arrange a meeting with you to discuss the offer and nail down the details.

Finally, we’ll sign a contract and start working on your project right away.