Als Anthropic im November 2024 das Model Context Protocol vorstellte, war es ein offener Standard, um KI-Agenten mit Tools und Datenquellen zu verbinden. Bis 2026 ist daraus in der Finanzbranche etwas Spezifischeres geworden: die Integrationsschicht, über die Agenten deterministische Systeme erreichen, Banking-Plattformen, Ledger, Warehouses, Marktdaten-APIs und GRC-Workflows, über eine standardisierte Client-Server-Schnittstelle.
Die Adoptionsevidenz ist inzwischen öffentlich statt anekdotisch. Grasshopper Bank lieferte im August 2025 aus, was als erster MCP-Server einer US-Bank beschrieben wurde, gefolgt von Bud Financial im Oktober 2025, GoCardless im Februar 2026 sowie Nymbus und Meow Technologies im April 2026. IBMs OpenPages 9.2 erreichte im März 2026 die allgemeine Verfügbarkeit mit Agentenzugriff auf Enterprise-GRC-Workflows, und ein Marktüberblick vom März 2026 zählte 31 Finanz-MCP-Server gegenüber insgesamt mehr als 4.000 Servern in öffentlichen Registries. Die Adoption ist real, und sie ist früh: Viele Deployments sind Piloten oder eng umrissene Produktions-Use-Cases, keine bankweiten Rollouts. Die interessante Frage hat sich verschoben, von ob man MCP nutzt zu wie man es unter aufsichtlicher Prüfung betreibt.
Ein Stack schmaler Server, nicht ein breiter
Das Architekturmuster, das sich durchgesetzt hat, ist nicht der eine riesige Bank-MCP-Server. Es ist ein Multi-Server-Stack mit strikten Scopes, Read-only-Defaults und zentralisierter Governance. Die Kategorien sind marktweit konsistent:
- ERP, Buchhaltung und Finance Operations. NetSuite, QuickBooks, Stripe und Spreadsheet-nahe Systeme, in denen Agenten bei Finance-Ops-Workflows assistieren.
- Data Warehouses und Analytics. Deployments im Stil von Snowflake, die Agenten kontrollierten Zugriff auf Reporting- und Analysedaten geben.
- Marktdaten und Trading. Preise, Fundamentaldaten, Screening, Indikatoren und alternative Datensätze, die dichteste Kategorie in öffentlichen Registries.
- Compliance und Evidenz. SOX-Evidenzsammlung, Access Reviews, Audit-Unterstützung und Compliance-Prüfungen.
- Kernbanksysteme und Zahlungsverkehr. Salden, Transaktionen und Zahlungsauslösung. Das ist die Kategorie mit dem höchsten Risiko und den stärksten Kontrollen.
Schmale Server gewinnen aus demselben Grund wie schmale Services: kleine Scopes, überprüfbare Änderungsflächen und ein Schadensradius, der bei einem Vorfall innerhalb eines Systems bleibt. Ein Server, der Warehouse-Lesezugriffe mit Zahlungs-Schreibzugriffen mischt, zwingt dazu, jedem Konsumenten auf dem Niveau seines gefährlichsten Tools zu vertrauen.
Autorisierung ist das eigentliche Designproblem
Das dominierende Muster 2026 sind gescope-te Credentials nach dem Least-Privilege-Prinzip: Read-only als Default, während Schreibzugriffe, Zahlungen, Rückerstattungen, Kontoänderungen und Datenexporte eine explizite Genehmigung erfordern. OAuth und SSO haben sich als empfohlene Autorisierungsschicht etabliert, weil sie dem Unternehmen zentrale Policy und Widerrufbarkeit geben, und Sicherheitsleitlinien für regulierte Branchen ergänzen rollenbasierte Scopes und zeitlich begrenzten Zugriff.
Die Feinheit, auf die es ankommt: Kontrolle auf Tool-Ebene schlägt Vertrauen auf Server-Ebene. Ein einzelner MCP-Server exponiert routinemäßig risikoarme Lese-Tools und risikoreiche Schreib-Tools nebeneinander, das nützliche Policy-Primitiv ist daher, einen Server zuzulassen und einzelne Tools darin zu blockieren. Die Identität des Agenten wird als Non-Human Identity mit eigenem Lebenszyklus behandelt: Der MCP-Server ist eine Enterprise-Applikation mit begrenzter Vertrauensgrenze, keine freie Assistentenverbindung. Anweisungen in einem System-Prompt sind keine Kontrolle. Ein Credential, dem der Scope fehlt, ist eine.
Prompt Injection ist ein Risiko auf Protokollebene
Finanz-MCP-Leitlinien behandeln Prompt Injection als Eigenschaft des Protokolls, nicht eines einzelnen Modells. Ein Agent nimmt Inhalte aus Webseiten, Dokumenten, E-Mails, Tickets oder Tool-Antworten auf, und jeder dieser Inhalte kann Anweisungen tragen, die einen Tool-Aufruf auslösen. Im Finanzbereich sind die schlimmsten Fälle konkret: nicht autorisierte Überweisungen, Datenexporte, Kontoänderungen oder stille Policy-Umgehungen, ausgelöst durch ein harmlos wirkendes Dokument.
Die empfohlene Mitigation ist Inhaltsinspektion auf Protokollebene, angewendet auf Tool-Aufrufe und Tool-Antworten gleichermaßen, mit kontextbewusster Erkennung statt Regex-Filterung. Aber Inspektion ist eine Schicht, nicht die Antwort. Die Unternehmenshaltung, die 2026 trägt, lautet, dass MCP-Server nur in Kombination sicher sind: Sandboxing, gescope-te Credentials, Genehmigungs-Gates für folgenreiche Aktionen und End-to-End-Auditierbarkeit. Jede Schicht geht davon aus, dass die darüberliegende gelegentlich versagt.
Wo MCP gegenüber den Alternativen steht
Jede Fähigkeit, die MCP bietet, existierte vorher in irgendeiner Form, und genau deshalb lohnt der Vergleich. Direkte APIs und SDKs sind ausgereift und explizit, aber jeder KI-Client braucht seine eigene Integration, die Arbeit fragmentiert und dupliziert sich also. iPaaS-Plattformen steuern Orchestrierung gut, sind aber weniger nativ für das Tool Calling von Agenten. RPA erreicht Systeme ohne APIs und ist fragil und schwer zu steuern. Eine REST- oder GraphQL-Fassade zentralisiert die Schemakontrolle, lässt die Agentenintegration pro Client aber weiterhin zu bauen übrig. MCPs Beitrag ist Portabilität: ein Tool-Schema, das jeden konformen Client bedient. Sein Preis ist, dass Governance, Autorisierung und Injection-Kontrollen selbst beizusteuern sind.
Dieser Tausch erklärt, wo die Adoption am stärksten ist: bei Instituten, die bereits ausgereifte APIs und rollenbasierte Kontrollen haben und bei denen MCP die Integrationsduplizierung über KI-Clients hinweg beseitigt, statt fehlende Fundamente zu übertünchen.
Betrieb unter aufsichtlicher Prüfung
An den Run-State-Kontrollen entscheidet sich, ob regulierte Deployments gelingen oder stecken bleiben. Zugelassene Server leben in einer kuratierten Registry, per Whitelist statt per Discovery, denn beliebige Server-Discovery ist eine offene Tür. Das Inventar ist kontinuierlich, keine Jahresübung, da sich Server und ihre Tool-Listen unter der Hand ändern. Das Audit-Logging erfasst Zeitstempel, Nutzer, Gerät, Agent, Server, Datenklassifikation und die ausgeführte Aktion, in einer Granularität, mit der ein Prüfer rekonstruieren kann, ob ein Mensch oder ein Agent eine bestimmte Sache getan hat und unter wessen Autorität.
Die Sequenzierung folgt dem Risiko. Leselastige, ermessensarme Workflows kommen zuerst: Warehouse-Abfragen, Marktdaten, GRC-Evidenz. Schreibaktionen kommen später, einzeln abgesichert, mit Genehmigungs-Workflows für alles, was Geld bewegt oder ein Konto ändert. Die Restriktion der Finanz-MCP-Adoption 2026 sind nicht die Use Cases, und das Wachstum des Governance-Toolings neben dem Protokoll zeigt, wo die eigentliche Arbeit liegt. Das Protokoll ist etabliert. Die Kontrollen sind das Projekt.
Häufige Fragen
Sollte jedes System einen eigenen MCP-Server bekommen, oder sollten wir ein Gateway bauen?
Beides, auf unterschiedlichen Ebenen. Schmale Server pro System halten die Scopes klein und die Reviews handhabbar, während ein Gateway davor einen zentralen Ort für Authentifizierung, Policy-Durchsetzung, Inhaltsinspektion und Logging schafft. Zu vermeiden ist der eine breite Server, der alles exponiert, denn Scoping und Change Review verschlechtern sich mit jedem hinzugefügten Tool, und eine einzige Kompromittierung erreicht den gesamten Bestand.
Wie lassen wir Agenten Salden lesen, aber niemals Geld bewegen?
Unterhalb des Prompts durchsetzen. Lese- und Schreibzugriffe sollten getrennte Tools mit getrennten Scopes sein, idealerweise auf getrennten Servern, wobei dem Credential des Agenten der Schreib-Scope schlicht fehlt. Zahlungsauslösung, Rückerstattungen und Kontoänderungen sitzen hinter expliziten Genehmigungs-Workflows mit einem Menschen am Gate. Anweisungen an das Modell sind keine Kontrolle; ein Credential, das das Tool nicht aufrufen kann, ist eine.
Ist MCP reif genug für ein reguliertes Institut?
Das Protokoll ist etabliert und Bankdeployments sind öffentlich, aber die meisten sind Piloten oder eng umrissene Produktions-Use-Cases statt bankweiter Rollouts, und das Governance-Tooling holt noch auf. Die pragmatische Lesart: MCP ist dort bereit, wo bereits ausgereifte APIs und rollenbasierte Kontrollen dahinterstehen, und die Deployments, die vorankommen, sind zuerst leselastig und ermessensarm, mit separat abgesicherten Schreibaktionen.