Agentic Workflow Patterns in Banking and Financial Services

Banking's AI stall has nothing to do with budget. A credit analyst approving a single loan today has to pull data from eight separate systems: core banking, the transaction warehouse, a sanctions database, KYC documents, the credit scoring model, regulatory capital tables, and a compliance sign-off, each connected by its own custom integration. That's the structural ceiling this piece is about, and why a protocol layer, not another model upgrade, is what actually unlocks agentic AI in a regulated bank.

Banking's integration debt made agentic AI structurally impossible without a protocol layer

When a bank deploys an agent, it needs its own connector to every system it touches. The credit decisioning example makes the scale of this concrete: querying core banking, a transaction data warehouse, a sanctions database, KYC documents, a credit scoring model, regulatory capital tables, and a compliance agent means touching eight systems and running dozens of point-to-point integrations, every one of them a potential point of failure in an environment where failures carry legal consequences, as the BFSI implementation guide frames it.

The Arcade enterprise MCP guide finds the same bottleneck in KYC onboarding, AML investigation, and payment reconciliation, workflows that remain largely manual despite decades of digital transformation spending. A human using a broken API call notices the error and routes around it. An agent chaining actions across seven or eight systems has no such instinct: one broken link anywhere in that chain fails the entire workflow and leaves behind a gap nobody can audit after the fact. That's a different category of failure than a single bad API call inside a process a person is actively supervising, and it's the reason the old integration model, tolerable for twenty years, becomes untenable the moment agents start acting on their own.

What MCP changes about the access model in banking

Model Context Protocol collapses the integration math from N agents times M systems down to N plus M connections. Instead of every agent building its own custom connector to every data source, MCP servers act as standardized gateways: agents invoke tools through one common protocol, and the server handles translation to whatever system sits behind it, as Arcade's enterprise MCP guide describes. Role and Policy Enforcement sits above both as the centralized governance layer, so it restricts which agents can invoke which actions and enforces the business and regulatory guardrails a bank actually needs.

Banking adds a wrinkle most MCP deployments never face: the legacy bridge. The agent never touches the legacy protocol directly.

That efficiency gain comes with a sharper risk attached. Something has to.

Dozens of custom connectors, each independently audited and each a compliance liability, is the N×M integration problem, and governed MCP protocols are designed to solve exactly that. Credal operates permissioned MCP servers across more than 1,000 connectors, collapsing that fragmented integration surface into a centralized registry and protocol layer where access controls, permissions, and audit trails are enforced at execution time rather than rebuilt for every new agent-to-system pair.

The governance baseline every production banking MCP deployment requires

Every production banking agent built on MCP shares a governance floor: the condition regulators attach to letting multi-system agentic action happen.

Transport security comes first: every connection between an MCP client and an MCP server needs mutual TLS, with both sides presenting certificates and both sides verified, for any connection that touches regulated financial data, as the BFSI guide specifies. Access control then has to operate at the tool level, not just the server level. Server-level permissions are too blunt an instrument for a regulated environment; the boundary has to sit at the individual action.

The BFSI implementation guide recommends going further than the base MCP spec allows by adding an authorization_context field, one not present in the standard protocol, that links every single tool call to the specific workflow and regulatory purpose that authorized it.

The regulatory clock backs this up. Governance is a legal precondition for operating, not a best practice banks can choose to adopt on their own timeline.

Entitlements and audit hooks cannot be bolted onto a system after it's already running. As Arcade's guide puts it, AI works best when it runs on infrastructure where governed data access and deterministic runtime control are built in from the start, not patched in once something has already gone wrong. Four requirements follow from that principle. Favoring narrow, explicit tools over generic ones also matters: a function like get_revenue_for_month(month, year) constrains what an agent can do far more effectively than a generic execute_sql(query) pattern, cutting the space for hallucination and making authorization something you can actually reason about.

Credit decisioning: how a governed multi-agent pattern compresses a 48-hour process to seconds

Credit decisioning is the clearest proof of what this governance baseline makes possible, because it demands the most systems, the tightest permissions, and the most complete audit trail of any banking workflow. The chain runs through the core banking system, the transaction data warehouse, a sanctions database, KYC documents, the credit scoring model, regulatory capital tables, and a compliance agent, all feeding into a single decision, as the BFSI guide describes.

Before this pattern existed, that chain took 24 to 48 hours end to end, with each data pull handled manually or semi-automatically and the audit trail stitched together after the decision was already made. Now a protocol-native agentic stack compresses that same chain to 6 to 12 seconds end to end, and the authorization_context field ties every tool call to the specific workflow and regulatory purpose behind it.

The governance design choices that make this safe are specific to each case. The credit scoring agent can read transaction patterns but has no ability to modify credit limits, with tool-level RBAC enforced the moment the tool is invoked. Because every tool call already carries the regulatory purpose that authorized it, the audit trail exists by construction.

This pattern also shows MCP working alongside a second protocol. Where MCP connects agents to systems, the Agent-to-Agent protocol connects the credit agent to the compliance agent, and the BFSI guide treats these as complementary layers. Implementation patterns from Arcade's guide reinforce the same point: MCP-powered systems generate alerts and decisions from holistic customer activity models, incorporating cash flow trends, seasonality, pending transactions, and peer benchmarking.

KYC orchestration: why identity verification became the template for governed multi-source workflows

KYC onboarding brings out problems credit decisioning mostly avoids. It pulls from identity document verification, sanctions and PEP screening, beneficial ownership lookups, internal customer history, and regulatory filing, sources that mix internal systems, third-party data providers, and government registries in a way credit decisioning's mostly-internal chain doesn't.

The legacy bridge creates the sharpest challenge here. MCP servers running in secure zones talk to legacy KYC systems through message queues or file transfers, presenting a clean, standardized MCP interface to the AI agents making requests, as the BFSI guide describes. The agent itself never has to speak the legacy protocol.

KYC also introduces consent as a governance requirement in its own right. Grasshopper Bank, running on Narmi's infrastructure, deployed the first MCP server at a US bank with a deliberate read-only constraint, a permission decision. Griffin, regulated by the UK's PRA and FCA, went further, becoming the first UK bank with full read-write MCP capabilities, with regulatory authorization built into the server design from day one rather than added once the pilot had already proven itself. So the contrast between the two shows the same governance principle applied at different levels of risk tolerance.

Fraud detection and AML investigation: the pattern where real-time data access and audit trails are both non-negotiable

Fraud detection and AML investigation put speed and governance in direct tension, and MCP's contribution is removing that tension. Because tool-level authorization combines with the authorization_context field, the audit trail arrives as a byproduct of real-time execution, not a separate logging task bolted on afterward.

AML investigation is a different animal entirely, but it shares the same governance baseline. The BFSI guide describes a permission design that holds the line in both cases: a fraud detection agent can read transaction patterns but can't modify a credit limit or initiate a transfer, a boundary enforced the moment the tool is called.

Meow Technologies, which launched its agentic banking platform in April 2026, built this directly into its architecture, embedding transfer limits, two-factor authentication, and role-based controls at the permissioning layer itself rather than layering them on top of a system that wasn't designed with them in mind.

Regulatory reporting: the workflow where the accuracy and latency improvements are the governance argument

Regulatory reporting produces the most measurable output of any of these patterns: a report that's auditable by construction, produced in hours instead of days, and verifiably more accurate than what came before. That output is itself the argument for the governance architecture behind it.

The BFSI guide identifies three regulatory frameworks behind this in European banking: DORA, the EU AI Act, and Basel III, with regulatory reporting as the workflow where all three intersect at once. The bounded tool set, 19 specific tools rather than open-ended SQL access, is the governance decision, not a constraint the bank plans to loosen later. Modern Treasury's payment operations MCP server follows the same logic for ACH, wire, and real-time payment automation, with an authorization model built around the specific payment rail.

You don't get this auditability from a separate compliance step layered onto the reporting process. It's that the tool calls which assembled the report carry their authorization contexts with them, so a regulator examining any figure in the report can trace it back to the exact query and the business decision that justified running it. That's a different kind of document than one assembled from a pile of spreadsheet exports.

Uber's scaling failure and the governance infrastructure banks will need next

Every pattern above works when one team owns it. Uber's experience with MCP adoption shows what happens when the harder problem goes unaddressed: making it work across hundreds of teams at once, without permissions fragmenting or the same workflow getting built five separate times.

As MCP adoption spread across Uber, individual teams built their own integrations independently, which led to fragmented tooling and duplicated infrastructure. Without a unified architecture in place, scaling up only added operational complexity and security risk, rather than the efficiency the protocol was supposed to deliver.

Banking faces a version of the same problem with sharper edges. When a developer spins up a local MCP server, IT and security teams get no visibility into it: no centralized audit trail, no access controls, no way to revoke permissions once that person leaves the company.

Uber's response was a three-layer fix. An LLM gateway handles PII redaction, access control, and observability logging across every model interaction. A registry with versioned ownership fixes that as much as it fixes the technical sprawl.

At Uber, a fragmented MCP deployment is an operational and security problem, and a tool call with no audit trail and no clear authorization context is a compliance gap.

The registry and gateway model that turns workflow patterns into institutional infrastructure

The patterns covered so far, credit decisioning, KYC, fraud and AML, regulatory reporting, only become durable institutional infrastructure once they're captured in a governed registry: versioned ownership, scoped access, and a central gateway enforcing permissions at the moment a tool is invoked, rather than each team rebuilding the same workflow from scratch.

A gateway model delivers three concrete things: simpler network plumbing than a web of point-to-point connections, fine-grained access control enforced right at tool invocation, and one audit surface instead of logs scattered across however many team-level servers happen to exist. A June 2026 extension to the enterprise authorization pattern formalizes how permissions get inherited rather than redefined: during SSO, the client trades the user's identity token for an ID-JAG, an Identity Assertion JWT Authorization Grant, which gets presented to the MCP server's authorization server to obtain an access token. Access control then runs through the organization's existing identity provider groups and roles, and every access generates a centralized audit trail automatically.

Credal is built around exactly this architecture. It operates as a governed registry where AI skills and MCP-backed agent workflows get captured once, versioned, and published company-wide. Each team gets its own scoped MCP server, with no separate interface to build or maintain, and that server plugs into whatever surface the team already uses, including Claude, ChatGPT, Cursor, and Slack, so the same governed context travels with the work. The design is also model-agnostic: business context, permissions, and guardrails travel with the organization rather than locking to a single LLM, which matters directly for banks running agents across more than one AI client and trying to avoid dependence on any single vendor's roadmap. That architecture is a direct answer to the Uber anti-pattern: one shared skill instead of five teams quietly rebuilding the same prompt, with the budget that saves going toward new capability.

Danske Bank sits at an earlier point on the same road. It's piloting an MCP service on top of its Premium APIs, so selected corporate customers can connect AI agents such as Claude and ChatGPT to view their own financial data under their own credentials. It's narrowly scoped, read-only, and customer-facing, which makes it less a competing approach than an illustration of where most institutions start before they need a full registry and gateway behind them.

Institutions in production versus institutions still piloting

The gap between a bank running a pilot and a bank running MCP in production is a governance gap, not a technology gap.

• Griffin (UK, regulated by the PRA and FCA): the first UK bank with full read-write MCP capabilities, with regulatory authorization built into the server design from the outset rather than retrofitted once the pilot had already worked.
• Grasshopper Bank, on Narmi's infrastructure: the first US bank MCP server, with its read-only scope reflecting a deliberate permission decision.
• Nymbus (April 2026): 19 named tools covering core banking functions, where the bounded tool set is itself the governance design rather than a limitation scheduled for later expansion.
• Meow Technologies (April 2026): an agentic banking platform with transfer limits, two-factor authentication, and role-based controls built into the permissioned architecture itself, not added on top of it.
• Modern Treasury: a payment operations MCP server handling ACH, wire, and real-time payment automation, with an authorization model specific to each payment rail.
• Danske Bank: piloting an MCP service on its Premium APIs for selected corporate customers under their own credentials, read-only and customer-scoped, still in pilot because the governance model for broader access isn't built yet.

Across every production deployment on that list, permissions get enforced at execution time, the audit trail is a byproduct of the tool call rather than a separate task, and the tool set stays narrow and explicit rather than defaulting to generic SQL or broad API access.

What stalls the rest is treating MCP governance as a checkbox to clear right before launch, instead of an architectural property designed in from the beginning. That failure mode occurs at scale: 80% of organizations moving agent-based systems into real workflows report running into unexpected behaviors, including improper data exposure and unauthorized system access. The institutions that scale from here won't be the ones that moved fastest into pilot. They'll be the ones building governance into the architecture now, ahead of the next wave of regulatory deadlines.