MCP for Agent-Access Banking

Open banking made regulated financial access programmable. Account information and payment initiation moved from bank-owned channels into application programming interfaces, which allowed approved providers to build financial products around data held by the institution. Open Banking Limited reported that the UK ecosystem passed 100 billion API calls across the CMA9 banks, with 2.81 billion calls recorded in June 2026. That volume shows that API access has become operating infrastructure rather than an integration experiment.

The success of open banking also exposes the boundary of its model. APIs give external organisations a repeatable connection to financial systems, but the customer experience still depends on another company building a product around that connection. The institution supplies access, while the external application defines how the customer uses the financial capability.

Agentic AI changes the consumer of financial connectivity. The customer’s AI environment can become the place where financial context is interpreted and instructions are prepared, which moves the access layer closer to the customer’s working environment. Model Context Protocol, or MCP, becomes relevant because it gives AI clients a defined way to discover approved tools exposed by external systems. The MCP tools specification describes server-exposed functions that language models can invoke, with tool availability able to vary according to the authorisation presented on the request.

Why Open Banking APIs do not solve agent access

Open banking was designed around application access. A regulated provider connects to the institution’s API and creates a product experience around the connection. The model works when the main objective is to allow approved applications to use account information or initiate payments.

Agentic finance creates another operating condition because the consuming system can interpret the customer’s instruction. The AI client does not require every financial task to be pre-built inside a separate application. The institution therefore needs a way to describe approved financial capability in a form the AI client can request under a defined permission model.

MCP provides that description layer above existing APIs. A tool exposed through MCP can call an existing account service and apply the institution’s entitlement rules before returning a controlled response. The API still performs deterministic system work, while MCP changes how the capability becomes available to the AI client.

This distinction is important for financial institutions that already invested in API infrastructure. The next step is not to replace those interfaces. The next step is to make selected capabilities discoverable to authorised agents without moving financial state away from the regulated platform.

How MCP changes the distribution model

Digital banking strategy has treated the institution’s own application as the primary customer interface. That assumption made sense when the mobile channel was where customers viewed balances and initiated transfers.

Investment in the application was therefore closely linked to engagement.

Agentic AI weakens the connection between product ownership and interface ownership. A customer may prefer to work inside one AI environment that connects to several financial providers. The useful interaction happens where the customer is making a financial decision, while each institution remains responsible for the records under its control.

This development changes what digital availability means. A bank may have a strong mobile application and still be difficult to use inside an agent-driven workflow if its capabilities cannot be discovered by authorised AI clients. The institution needs an access layer designed for machine interpretation as well as human interaction.

The commercial effect will appear first where financial information is fragmented. A small business may need a liquidity view that depends on banking records and accounting data. A personal investor may need account context from one institution and position data from another. Under an MCP model, the institution provides governed access to its own capability while the AI environment assembles the working context.

Why proprietary AI is a costly first move

Large digital financial institutions can justify proprietary AI propositions when customer volume supports permanent product ownership. Revolut launched AIR in April 2026 as an in-app AI assistant, placing AI inside its own customer environment. That approach is more defensible when the institution already operates at large digital scale.

Mid-market institutions face a different investment problem because they cannot spread the cost of a proprietary assistant across the same customer base. A financial assistant becomes a controlled operating layer once it starts interpreting customer context and preparing regulated actions. The programme then extends beyond conversational design into the relationship between model behaviour and institutional authority.

That operating layer requires permanent ownership. The institution has to maintain the relationship between AI output and financial controls, then produce evidence that customer-facing actions follow approved rules. As the assistant moves from balance queries into payment preparation, the risk profile changes because the workflow begins to touch validation logic and approval routing.

MCP changes the investment sequence. Instead of building a complete AI destination, the institution can first expose controlled read access through an MCP server. More sensitive actions can follow where authentication rules and approval authority are mature enough. The investment shifts toward governed access to existing financial capability rather than ownership of a proprietary AI interface.

Building the control boundary for financial MCP

Financial MCP cannot operate as a simple protocol adapter in front of sensitive systems. The institution needs a defined authority model before any capability becomes available to an AI client. That model must determine which client can access which data and which user can approve execution.

The protocol provides part of the technical basis. MCP authorisation supports restricted servers at the transport level, which allows clients to make requests on behalf of resource owners. The banking implementation must still translate that basis into consent rules and entitlement checks that reflect the institution’s operating model.

The AI client should interpret intent and call an approved capability. The institution should control authentication and execution, while existing systems produce definitive outcomes and audit evidence. This separation allows agent access without transferring financial authority to the AI layer.

Agent-access readiness therefore depends on banking fundamentals. The institution needs reliable data and deterministic APIs before exposing capabilities to external AI clients. Weak records or unclear authority models will become visible quickly when agents begin requesting financial operations across internal systems.

Preparing existing cores for agent access

Most institutions will not replace core systems to participate in agentic finance. The practical implementation places MCP above the existing core and orchestration layer, with current API endpoints continuing to provide controlled access to financial data. This approach preserves the systems that already carry financial authority while adding an interface designed for AI consumption.

For institutions with mature APIs, implementation begins with capability mapping rather than model selection. Each MCP tool needs a defined purpose and permission requirement. The same tool needs an exception path and downstream owner before the institution makes it available to an external AI client.

For institutions with older infrastructure, middleware may need to create stable service boundaries before MCP exposure becomes safe. If the institution cannot return reliable account states or enforce entitlements consistently, an MCP server will make those weaknesses visible to a more dynamic consumption layer. The work is therefore operational as well as technical.

The adoption sequence should remain controlled. Institutions can begin with financial information that can be exposed safely, then add workflow preparation where approval rules are already clear. Execution should remain inside systems that already carry financial authority and produce audit evidence.

Deploying MCP with Finpace Halcyon

Finpace Halcyon is designed for financial institutions that need an MCP layer without rebuilding their core architecture around AI. Halcyon enables institutions to deploy MCP servers on top of existing core banking and connected financial systems, using current APIs where those interfaces already provide reliable access to financial capability.

The core remains responsible for financial state and financial authority. Existing services continue to manage regulated operations and back-office evidence. Halcyon provides the agent-facing layer through which approved data and workflows can be exposed to MCP-compatible clients under the institution’s permission model.

This implementation path is relevant for institutions that need to participate in agentic finance before committing to a proprietary AI assistant. Open banking proved that regulated account access could operate outside proprietary bank channels. MCP extends that principle to AI clients, where approved financial capability can be used through the customer’s chosen environment while execution remains inside the institution’s control environment.