--- title: "MCP for Banks: What the Protocol Requires and the Bank Designs - S-PRO" url: https://s-pro.io/blog/mcp-for-banks lang: en description: "MCP authorization is optional, so the bank's server carries the controls. See what the spec requires, what banks design, and why client-login agents get blocked." updated: 2026-11-09T06:06:02+00:00 source: S-PRO (https://s-pro.io) --- [Back to insights](https://s-pro.io/blog) Article # MCP for Banks: What the Protocol Requires and the Bank Designs Author [Igor Izraylevych](https://s-pro.io/author/igor-izraylevych) CEO and Co-founder of S-PRO Published November 5, 2026 Time to read 14 min Table of content - Key Takeaways - Table of Contents - What MCP is, and what it leaves to the bank - What the specification requires - Client-login agent versus sanctioned MCP or API - Why banks block client-login agents - What the bank designs: our reading - Swiss regulatory frame - From pilot to production - Our perspective - Build the sanctioned route with S-PRO - FAQ - How S-PRO helps banks and financial institutions - Sources Share Authorization in the Model Context Protocol (MCP) is optional, according to the [MCP specification, version 2026-07-28](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization), which we read on 26 October 2026. The bank’s own MCP server therefore has to carry the controls: who may call which tool, with what scope, under whose consent, and with what record. This article separates what the protocol itself requires from what a bank has to design around it. It also explains why an agent that logs in with a client’s own credentials is a different thing from a sanctioned MCP or API connection. We found no regulator text that addresses MCP by name, so where we describe design, it is our reading of the spec and of Swiss supervisory material. S-PRO Build Governed AI for Banking S-PRO builds AI agents and financial software for banks, with solutions designed around requirements including FINMA and DORA. [Explore S-PRO](https://s-pro.io) ## Key Takeaways - The MCP spec makes authorization optional. When a server uses HTTP, it points to OAuth 2.1, and the server must validate the audience of every token and must not pass tokens through to other services. - Everything the spec leaves open (consent, tool inventory, approval thresholds, audit logging, liability) is the bank’s design work, and it sits on the server side. - An agent that logs in as the client shares a credential and has no bounded scope. A sanctioned MCP or API connection gives the agent its own identity, scoped access and an audit trail. - In Switzerland, FINMA Circular 2023/1, the revised FADP and outsourcing rules frame the design. A tool permission inventory is a practical artifact to start with. - A pilot is not a production service. Sygnum’s May 2026 pilot shows the pattern: controlled conditions first, full reviews before production. ## Table of Contents - What the specification requires - Why banks block client-login agents - What the bank designs: our reading - Swiss regulatory frame - From pilot to production - Our perspective - Build the sanctioned route with S-PRO - FAQ - Sources ## What MCP is, and what it leaves to the bank MCP is an open standard that defines how digital services can be structured so AI systems can access and interact with them in a controlled way, as the [Swiss Bankers Association describes it](https://www.swissbanking.ch/en/media-politics/blog-posts/ai-driven-advice-with-mcp-a-new-era-in-client-interaction) (12 December 2025). It was published at the end of 2024 and provides functions, data sources and reusable templates that link a bank’s systems to AI models. The architecture has three parts. The client application gathers context such as role and permissions. The model receives that context and a list of available tools. The server hosts the approved tools, APIs and databases and executes authorized actions. The protocol standardizes the conversation between these parts. It does not decide which actions a bank should expose, to whom, or under what limits. That split matters for anyone buying or building. A bank that says “we support MCP” has said little about control. The statement that matters is what the MCP server permits and how it proves it. ## What the specification requires The specification keeps authorization optional, and where a server uses HTTP-based transport and authorization, it relies on OAuth 2.1, which is still an [IETF draft](https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/). Within that, the spec sets several firm rules that matter for a bank. - **Audience validation.** The MCP server MUST validate that an access token was issued for that server, meaning the token audience matches. - **No token passthrough.** The server MUST NOT pass through the token it received to downstream APIs. If the server calls another service, it obtains a separate token for that service. - **Least-privilege scopes.** Scopes should be minimal and specific to the tools exposed. Wildcard or catch-all scopes are not the model. All three rules are in the [authorization section of the spec](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization). Their purpose is easy to see in a banking context. Audience validation stops a token issued for one service from being replayed against another. The ban on passthrough keeps each hop in the chain separately accountable, so a log entry names the party that acted. Narrow scopes keep a compromised or misdirected agent from reaching more than a task requires. Note what is absent. The spec does not define client consent screens for a bank’s regulatory purposes, a tool inventory, approval thresholds for high-value actions, retention of logs, or who bears loss when an instruction turns out to be wrong. Those are design decisions. ## Client-login agent versus sanctioned MCP or API A client-login agent acts by borrowing the client’s username and password or session (background: [agentic banking](https://s-pro.io/blog/agentic-banking)). A sanctioned MCP or API connection gives the agent a registered identity with scopes the bank has defined. The table sets out the difference on the five points that matter in a risk review. | Dimension | Client-login agent | Sanctioned MCP or API connection | | --- | --- | --- | | Credential | The client’s own login is shared with a third-party agent | The agent holds its own token, issued by the bank’s authorization server for a specific server (audience) | | Scope | Everything the client can do in the app, with no narrowing | Least-privilege scopes per tool, no wildcards | | Consent | Implicit: the client typed in a password | Explicit and recorded, per client and per purpose, and revocable | | Audit trail | The bank sees a client session and cannot tell human from agent | Tool-call level log: tool, parameters, result, agent identity | | Liability | Unclear: the client shared credentials, the agent acted, the bank cannot attribute the action | Defined in the access terms: who authorized, who acted, who answers for an incorrect instruction | The row on audit trail carries the most weight. If a bank cannot distinguish an agent acting from a person acting, it cannot meet its own record-keeping and risk-management duties for that activity. The row on liability follows from it. [The Digital Banker’s analysis of HSBC’s new platform](https://thedigitalbanker.com/hsbc-launch-hsbcnio-to-allo-clients-connect-ai-to-banking-data/) (2 November 2026) draws the same line from the other side: letting AI retrieve information raises authentication and data-protection questions, while letting it act raises whether the instruction is genuine, whether the agent has authority, and who is responsible if the instruction is wrong or fraudulent. ## Why banks block client-login agents Banks block these agents because a shared credential removes the controls a bank relies on: it cannot scope the access, cannot prove consent, and cannot attribute the action. This is our reading of how the pieces fit together, not a regulator’s statement. Three practical reasons follow from the table. 1. **The credential is shared with a party the bank has not assessed.** The agent provider, and the model behind it, may process the data outside the bank’s perimeter. 2. **The access cannot be narrowed.** A login that can view a balance can usually also initiate other actions. The bank’s only lever is to allow or refuse the session. 3. **Responsibility cannot be assigned.** If an agent misreads an instruction, the record shows a client logging in. That is a poor basis for any dispute or any supervisory conversation. The constructive answer is not to refuse agents. It is to offer a route that does what a client-login cannot: a sanctioned interface where the agent authenticates as itself, receives scoped tokens and leaves a record. HSBC’s announcement of HSBCnio on 26 October 2026, as [reported by The Digital Banker](https://thedigitalbanker.com/hsbc-launch-hsbcnio-to-allo-clients-connect-ai-to-banking-data/), is one example: corporate and institutional clients connect their own AI applications to authorized account and transaction information through an MCP-supporting platform, and the AI tools can retrieve and analyze data but cannot independently move money. ## What the bank designs: our reading The bank designs the permission model, the approval rules and the evidence trail on its MCP server. We found no regulator text on MCP, so the following is our reading, built from the spec and from Swiss material on agent access. The [Swiss FinTech Innovations white paper on AI agent access to APIs](https://swissfintechinnovations.ch/wp-content/uploads/2026/02/SFTI-White-Paper-Reference-architecture-for-AI-agent-access-to-SFTI-APIs.pdf) (26 February 2026) is the most concrete Swiss reference we have found. Its controls include short-lived access tokens, HTTPS in production, least-privilege scopes per tool, no logging of credentials, role-based access control per tenant, schema validation against approved OpenAPI contracts, approval workflows for actions that cross risk thresholds, immutable audit logging, and a tool permission inventory. Here is how we would turn that into a plan. ### A seven-step design checklist 1. **List every tool.** For each, record the permission scope, the data it touches and the actions it can execute. This is the tool permission inventory. 2. **Separate identities.** The agent application, the MCP server and each downstream resource server hold different credentials. 3. **Issue short-lived, audience-bound tokens.** Validate the audience at the server and never forward the incoming token. 4. **Define scopes per tool.** No wildcards. Split actions that retrieve information from actions that change state. 5. **Set approval thresholds.** Require human confirmation for actions above a defined risk level, and decide who confirms. 6. **Log at tool-call level.** Capture the tool, parameters, result and agent identity, in a store that cannot be edited afterward. 7. **Record client consent.** Tie it to purpose and make revocation immediate. Two more details from the same material. The session identifier should be treated as untrusted input, and circuit breakers should stop calls to unhealthy services so that an agent does not keep retrying against a failing core system (more: [prompt injection defense for banks](https://s-pro.io/blog/prompt-injection-defense)). For teams whose core is the constraint, the interface layer often depends on how cleanly the underlying systems expose capabilities. That is where core and legacy modernization work and a well-defined API layer pay off before any agent is connected. > **If your agent pilot already works but nobody can say who may call which tool:** we can review your MCP server design with you and turn it into a permission model your risk and compliance teams can sign. Talk to our engineers. ## Swiss regulatory frame In Switzerland, no single rule governs MCP, so the design has to satisfy the existing frame: FINMA’s operational-risk and outsourcing circulars, the revised FADP and banking secrecy. Check each against your own use case and legal advice. The SFTI paper describes the tool permission inventory as a required artifact under FINMA Circular 2023/1 on operational risks and resilience. You can read the circular on [the FINMA website](https://www.finma.ch/en/). FINMA Circular 2018/3 on outsourcing is relevant when the model provider or hosting sits with a third party. On data protection, the revised Federal Act on Data Protection has been in force since 1 September 2023. Its privacy-by-design and minimization principles bear on how broad an agent’s tool access can be. Our reading: an agent with access to systems holding personal data needs explicitly scoped access, which is what the scope rules above deliver. On outsourcing, [a Swiss law firm’s analysis](https://caplaw.ch/2022/the-impact-of-the-revised-data-protection-act-on-outsourcings-by-swiss-financial-institutions/) (7 June 2022) notes that clear-text client-identifying data may not be disclosed to an outsourcing provider without each client’s express consent, at least if the provider receives the data abroad. That matters if an agent’s model runs outside Switzerland. On human oversight, the Swiss Bankers Association’s [guideline on handling data](https://www.swissbanking.ch/_Resources/Persistent/1/a/2/6/1a2625f788831fcb3b930a97afa1d16fa7521caf/Guideline%20Handling%20data%20in%20day-to-day%20business.pdf) (May 2021) says bank staff are usually responsible for decisions based on AI outcomes. Where AI decides entirely without staff intervention, the consequences of automated individual decisions under Art. 21 revFADP should be investigated. That supports approval steps for consequential actions. ### EU AI Act dates for banks with EU activity If your bank serves the EU, the EU AI Act applies to the AI systems you deploy, not to MCP as a protocol. Under Regulation (EU) 2026/1744 (AI Omnibus), in force since 27 July 2026, stand-alone high-risk (Annex III) obligations apply from 2 December 2027, and high-risk AI embedded in products (Annex I) applies from 2 August 2028. The [European Commission’s AI Act page](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai) is the place to confirm current dates. For any agent use case, check Annex III against the use case. ## From pilot to production A pilot proves the connection works; production proves the controls hold. Sygnum, a Swiss digital asset bank, [announced in May 2026](https://www.sygnum.com/news/sygnum-completes-first-live-ai-agent-driven-digital-asset-transactions-by-a-regulated-swiss-bank/) that it used an AI agent to test live market transactions through an in-house MCP server with Claude as the model. The pilot ran under controlled conditions, with no client data, wallets or infrastructure, and production deployment stays subject to full regulatory, compliance and security reviews. The lesson for other banks is the sequence. Start with a bounded scope and no client data. Build the inventory and the log first. Then widen scope only after the reviews that your compliance, risk and security functions require. Our guide to moving AI agents from pilot to production covers that transition in more detail. ## Our perspective > We think of MCP as an interface decision before it is an AI decision. The protocol gives a bank a standard way to expose capabilities, and because authorization is optional in the spec, the bank decides how much control to build in. We build in all of it. > > > > In practice, that means treating the MCP server as a governed product: an inventory of tools, scopes that match tasks, tokens bound to the right audience, approval steps where an action matters, and a log that a compliance officer can read. Agents that borrow a client’s login cannot be governed this way, and we understand why banks decline them. > > > > The banks that make progress offer a sanctioned route and make it good enough that nobody needs the workaround. For relationship managers, onboarding teams and operations, that is also where AI agents become dependable enough to run in production. > > > > *The S-PRO team* ## Build the sanctioned route with S-PRO S-PRO builds AI agents for banks, and each solution is designed with EU AI Act, FINMA and DORA requirements in mind. Our AI agent development work covers the agent, the integration layer and the controls around it. If your first target is a customer-facing channel, our digital banking platforms practice can help expose the right capabilities safely. Talk to S-PRO about your AI agent project Get in touch ## FAQ ### Is MCP authorization mandatory? No. In the specification version 2026-07-28, authorization is optional. When a server uses HTTP, the spec points to OAuth 2.1, and the server must validate token audience and must not pass tokens through. A bank should treat authorization as required for its own server, because the controls are otherwise missing. ### Why do banks block agents that use a client’s login? A shared login cannot be scoped, cannot show the client’s consent, and cannot separate an agent’s actions from the person’s. That leaves the bank unable to attribute actions or define liability. A sanctioned MCP or API connection gives the agent its own identity, narrow scopes and a tool-call log. ### Does Swiss regulation mention MCP? We found no regulator text on MCP. Existing rules still apply to the design: FINMA Circular 2023/1 on operational risks, FINMA Circular 2018/3 on outsourcing, the revised FADP and banking secrecy. We read these as requiring scoped access, documented tools, human oversight and traceable logs. Check each against your use case. ### How can we start an MCP design? Begin with a tool permission inventory and a bounded pilot without client data. S-PRO offers a design thinking pilot from USD 20k, 2-4 weeks. It produces the scope, the permission model and the production plan, so your risk and compliance teams can review a concrete design. Last updated 3 November 2026 ## How S-PRO helps banks and financial institutions S-PRO is an international Swiss-American firm with offices in Zurich and Salt Lake City, and global delivery, founded in 2014, with 250+ engineers. We design and build MCP servers, permission models and audit logging for banks, and we run the solution as a service. We build each solution on our own agentic platform, S-PRO Agents. Our team includes Claude-certified engineers and architects, and S-PRO is a Certified partner in the Claude Partner Network. You can see how we approach Claude for financial services on our site. If you want to review an MCP design with engineers who work in regulated environments, book a discovery call. ## Sources - [MCP specification, authorization, version 2026-07-28](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization) - [OAuth 2.1, IETF draft](https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/) - [Swiss Bankers Association: AI-driven advice with MCP](https://www.swissbanking.ch/en/media-politics/blog-posts/ai-driven-advice-with-mcp-a-new-era-in-client-interaction) - [Swiss Bankers Association: Handling data in day-to-day business](https://www.swissbanking.ch/_Resources/Persistent/1/a/2/6/1a2625f788831fcb3b930a97afa1d16fa7521caf/Guideline%20Handling%20data%20in%20day-to-day%20business.pdf) - [The Digital Banker: HSBCnio](https://thedigitalbanker.com/hsbc-launch-hsbcnio-to-allo-clients-connect-ai-to-banking-data/) - [Swiss FinTech Innovations: Reference architecture for AI agent access](https://swissfintechinnovations.ch/wp-content/uploads/2026/02/SFTI-White-Paper-Reference-architecture-for-AI-agent-access-to-SFTI-APIs.pdf) - [FINMA](https://www.finma.ch/en/) - [Caplaw: revised Data Protection Act and outsourcing](https://caplaw.ch/2022/the-impact-of-the-revised-data-protection-act-on-outsourcings-by-swiss-financial-institutions/) - [European Commission: AI Act](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai) - [Sygnum: first live AI-agent digital asset transactions](https://www.sygnum.com/news/sygnum-completes-first-live-ai-agent-driven-digital-asset-transactions-by-a-regulated-swiss-bank/) Subscribe Get technical insights, and industry news Thank you! Get ready! You will receive handpicked content right to your inbox. --- Contact You will talk to engineers who build for banks, not to a sales script. Share your ideas, findings and questions with us. - **Security and privacy first**ISO 27001 and ISO 27701 certified. - **Claude Partner Network**S-PRO is a Certified partner in the Claude Partner Network. Our team includes Claude-certified engineers and architects. - **Proven in regulated finance**Banks, wealth managers and fintechs in Switzerland, the EU and the US. Who you’ll talk to **Michael Barskyi**Head of Banking & Fintech **Dustin Schulze**Senior Business Analyst Prefer email or phone? [hi@s-pro.ioEmail](mailto:hi@s-pro.io)[+41 41 539 15 83Phone](tel:+41415391583) Claude Certified Services Partner(Anthropic) **4.9**46 reviews on Clutch Contact us ### Send us your request Share your ideas, findings and questions with us. Link copied to clipboard Get in touch