MCP-Gateway für KI-Agenten im Bankwesen: die Steuerungsebene zwischen KI und Kernbankensystem

3. Juli 2026

10 Minuten Lesezeit

Digital connector showing secure links between AI agents and financial infrastructure.
Zusammenfassen mit KI

Im vorheriger Artikel, habe ich die vierstufige Vertrauensarchitektur für KI-Agenten im Bankwesen aufgeschlüsselt: Client-Ebene, Agenten-Orchestrierung, MCP-Gateway und Kernbankensystem. Dieses Modell vermittelt Ihnen einen Überblick über die Struktur des Systems. In diesem Artikel geht es um den Teil, der diese Struktur in der Praxis nutzbar macht.

Über das MCP-Gateway wird die Absicht des Agenten geprüft.

Ein Modell kann entscheiden, dass es Kontodaten, den KYC-Status, Zahlungsvorbereitungen, eine AML-Prüfung oder ein Betrugssignal benötigt. Im Bankwesen gilt “das Modell hat entschieden” jedoch nicht als Kontrollmaßnahme. Bevor diese Anfrage auch nur in die Nähe des Kernsystems gelangt, müssen Mandantenbereich, Benutzerberechtigungen, Schemavalidierung, Genehmigungsstatus, Audit-Kontext und Fehlerbehandlung geprüft werden. Das ist die Aufgabe des Gateways. 

Kommen wir also zu den technischen Details: RBAC, Schema-Prüfungen, Genehmigungsworkflows, Audit-Protokolle, Circuit Breaker, Token-Scoping und wie das im Rahmen eines Underwriting-Prozesses aussieht.

Blockchain-Experte und DeFi-Analyst

Andrew übersetzt dezentralisierte Konzepte in sichere, funktionale Finanztools. Er navigiert durch die unbeständige DeFi-Landschaft, um skalierbare Blockchain-Infrastrukturen aufzubauen, die einen realen Nutzen bieten und über die Schlagworte hinausgehen, um technischen Wert zu liefern.

Das MCP-Gateway als obligatorischer Engpass

Ich würde das MCP-Gateway zunächst anhand eines Kriteriums beurteilen: Kann es eine Anfrage ablehnen, die für den Agenten völlig in Ordnung erscheint? 

Das Modell wählt möglicherweise das richtige Tool aus, füllt die erwarteten Felder aus und erzeugt ein Ergebnis, das eine grundlegende Analyse besteht. Aus Sicht des Agenten scheint der Aufruf bereit zu sein. Aus Sicht der Bank fehlen jedoch möglicherweise noch entscheidende Informationen: Mandantenzugriff, Benutzerrolle, Workflow-Status, Genehmigungsschwelle, Beschränkungen des Quellsystems und Audit-Kontext.

Das Gateway hat also eine ganz bestimmte Aufgabe. Es überbrückt die Lücke zwischen “der Agent hat eine gültig erscheinende Anfrage generiert” und “die Bank darf auf diese Anfrage reagieren”. Es muss das Modell nicht intelligenter machen. Es muss dafür sorgen, dass die Aktionen des Modells überprüfbar, ablehnbar und sicher für die Weiterleitung sind. 

So verarbeitet das MCP-Gateway eine Agentenanfrage:

AI banking gateway diagram showing role checks, schema validation, approval rules, and final request handling.

Hinter dieser Entscheidung stehen sechs Kontrollmechanismen: RBAC auf Mieterebene, Schemavalidierung, Genehmigungsworkflows, unveränderliche Audit-Protokollierung, Circuit Breaker und Token-Scoping. Jeder dieser Mechanismen fängt eine andere Art von Fehler ab, bevor die Anfrage das Kernbankensystem erreicht.

Gateway-Steuerung
Was es blockiert oder steuert
Beispiel aus dem Bankwesen
RBAC pro Mandant
Zugriff auf Tools und Endpunkte nach Mandant, Rolle, Region und Workflow
Ein reiner Zahlungsanbieter kann Auszahlungen vorbereiten, kann jedoch keine KYC-Prüfungs-Endpunkte aufrufen.
Schema-Validierung
Anfragen, die nicht mit genehmigten OpenAPI-Verträgen übereinstimmen
Eine fehlerhafte Zahlungsnachricht scheitert, bevor sie den Zahlungsdienst erreicht
Genehmigungsabläufe
Vorgänge, die Schwellenwerte hinsichtlich Risiko, Betrag, Begünstigter oder Police überschreiten
Eine Transaktion mit hohem Wert wird in eine Genehmigungswarteschlange gestellt, anstatt direkt zur Ausführung weitergeleitet zu werden
Immutable-Auditprotokollierung
Der vollständige Anforderungsverlauf: Wer, Was, Wann, Mandant, Kanal, Genehmigungsstatus und Ergebnis
Die Compliance-Abteilung kann einen Export, aus dem personenbezogene Daten entfernt wurden, prüfen, ohne die Chat-Protokolle im Original lesen zu müssen.
Leistungsschalter
Aufrufe an unzuverlässige, langsame oder durch die Überlastungsgrenze eingeschränkte Kerndienste und Anbieter
Ein Ausfall eines AML-Anbieters löst eine Fallback-Benachrichtigung aus, anstatt wiederholte fehlgeschlagene Anrufe zu versuchen
Gültigkeitsbereich von Tokens
Zu weitreichender Zugriff auf Mieterdaten, Konten oder Anbieter-Tools
Ein kurzlebiges Token kann eine einzelne Kontoansicht abrufen, nicht jedoch den gesamten Datensatz des Mandanten.

RBAC Hier beginnt sich das Gateway zu amortisieren. In einer mandantenfähigen Banking-Plattform kann der Zugriff nicht pauschal gewährt werden, nur weil der Mitarbeiter “intern” ist. Jeder Mandant benötigt seine eigene Berechtigungsmatrix. Ein Händler, der ausschließlich Zahlungsauslösungen nutzt, sollte keinen Zugriff auf KYC-Tools erhalten. Ein Support-Mitarbeiter in einer Region sollte keine Kartenkontrollen für eine andere Region einsehen können. Ein Workflow, der lediglich eine Kontostandsabfrage benötigt, sollte keine Überweisungsvorbereitung erhalten.

Schema-Validierung ist der nächste Filter. Das Gateway sollte jede Anfrage anhand genehmigter OpenAPI-Spezifikationen oder gleichwertiger Verträge validieren. Dadurch werden fehlerhafte Payloads abgefangen: falsches Währungsformat, fehlende Empfänger-ID, nicht unterstützter Zahlungsweg, unmöglicher Datumsbereich, fehlerhafte KYC-Statusanfrage. Das Modell kann zwar eloquent sein und dennoch eine Payload erzeugen, die das System verwerfen sollte.

Genehmigungsabläufe Hier wird das Modell ohne Verwahrung konkret umgesetzt. Der Bearbeiter kann zwar eine Maßnahme vorbereiten, doch risikoreiche Vorgänge erfordern eine Warteschlange, beispielsweise bei Betragsgrenzen, neuen Begünstigten, verdächtigen Kontostatus, unvollständiger Identitätsprüfung (KYC), erhöhten Betrugssignalen oder mandantenspezifischen Richtlinien. Das Gateway sollte den Genehmigungsantrag erstellen, den Genehmiger benachrichtigen, Zeitlimitregeln überwachen und dem Nutzer oder Betreiber einen eindeutigen Status zurückmelden.

Protokollierung von Prüfvorgängen muss in den Ablauf integriert werden. Bei jeder Anfrage sollte das Gateway einen Datensatz erstellen, der nur um neue Einträge erweitert werden kann. Dieser Datensatz sollte Mandant, Benutzer, Kanal, Workflow-Status, Tool, Parameter nach der Anonymisierung, Validierungsergebnis, Genehmigungsstatus, nachgelagerte Antwort und Korrelations-ID enthalten. Compliance-Teams benötigen kein schön aufbereitetes Protokoll. Sie benötigen einen übersichtlichen Nachweis, der erklärt, warum das System die Aktion zugelassen oder blockiert hat.

Eine Unterscheidung, die es von Anfang an zu beachten gilt: Das Protokoll belegt, was ausgeführt wurde, nicht aber, wer dazu befugt war, dies zu veranlassen. Ein Trace kann zwar eindeutig zeigen, dass eine Übertragung unter einem bestimmten Token von A nach B erfolgte. Er kann jedoch für sich genommen nicht belegen, dass die Aktion von einem Auftraggeber autorisiert wurde, den beide Seiten anerkennen, oder dass die Autorisierung nicht bereits widerrufen worden war. In einem Single-Tenant-Ablauf ist diese Lücke nicht sichtbar, da sich das Protokoll und die Berechtigungsdatensätze am selben Ort befinden. Sobald ein Streitfall einen Mandanten oder eine Gegenpartei betrifft, wird genau diese Lücke zum Kernproblem. Daher sollte der Datensatz die Berechtigung erfassen: Welches Mandat hat den Aufruf autorisiert, in welchem Umfang und ob es zu diesem Zeitpunkt noch gültig war. Ich gehe in meinem Artikel näher auf diesen Punkt ein Ein Mandat ist nicht gleichbedeutend mit Regierungsführung.

Leistungsschalter Das ist ein Problem, weil Bankdienstleister auf langweilige Weise versagen – etwa durch Timeouts, teilweise Ausfälle, langsame Antworten, veraltete Statusmeldungen und Ratenbegrenzungen. Das Gateway sollte dieses Muster erkennen, einen erneuten Versuch mit Backoff unternehmen, wenn dies sicher ist, wiederholte Aufrufe unterbinden, wenn dies nicht der Fall ist, und dem Nutzer eine sinnvolle Alternative anbieten. “AML-Anbieter nicht verfügbar, bitte später erneut versuchen” ist besser, als den Agenten in einer Endlosschleife laufen zu lassen, einen Status zu erfinden oder einen beeinträchtigten Dienst weiter zu überlasten.

Gültigkeitsbereich von Tokens begrenzt den Schadensumfang. Ein Tool-Aufruf sollte nur die Mindestzugriffsrechte erhalten, die für diese spezifische Anfrage, diesen Mandanten, diesen Benutzer und diesen Workflow-Status erforderlich sind. Kurzlebige, bereichsgebundene Token sind wesentlich sicherer als langlebige Dienstzugangsdaten, die in der Agent-Ebene im Umlauf sind. Sollte etwas schiefgehen, sollte die fehlgeschlagene Anfrage nur begrenzte Auswirkungen haben.

Den Zugriff von KI-Agenten kontrollieren, bevor er das Kernbankensystem erreicht

Mit Innowise bleiben alle Vorgänge berechtigungsgebunden, nachvollziehbar und unter Ihrer Kontrolle.

Safeguard-Pipeline: 5 Sicherheitsmaßnahmen für KI-Agenten im Bankwesen

Über die Safeguard-Pipeline habe ich bereits im Artikel über Architektur, aber hier möchte ich das Thema aus einem strengeren Blickwinkel betrachten: Was wird überprüft, bevor das Modell mit der Planung beginnt, und was wird überprüft, bevor der Nutzer die Antwort sieht oder das System eine Aktion ausführt?.Das MCP-Gateway steuert den Zugriff auf Tools, während die Safeguard-Pipeline die Offenlegung und die Ausgabe von Modellen regelt. Sie liegen im Ablauf dicht beieinander, erkennen jedoch unterschiedliche Fehler.
Wache
Durchsetzungsmoment
Was passiert, wenn es nicht klappt?
Schnelle Erkennung von Injektionen
Bevor der Agent einen Werkzeugweg plant
Die Anfrage wird blockiert, von eingefügten Inhalten bereinigt oder zur manuellen Überprüfung weitergeleitet.
PII-Redaktor
Bevor der Kontext in das Modell einfließt
Nicht benötigte sensible Werte werden maskiert, tokenisiert oder aus der Eingabeaufforderung entfernt
Llama Guard/Sicherheitsklassifizierer
Bevor die Argumentation fortgesetzt wird
Der Ablauf wird blockiert, auf eine sichere Reaktion eingeschränkt oder eskaliert.
Erkennung von Halluzinationen
Bevor die Antwort angezeigt wird
Nicht belegte Forderungen werden anhand der Quellsysteme überprüft und anschließend korrigiert, erneut versucht oder gesperrt.
Compliance-Richtlinie Engine
Vor der Beantwortung, der Vorbereitung oder der Genehmigung
Die Aktion ist gesperrt, steht zur Genehmigung an oder wird gemäß den Mandantenrichtlinien neu geschrieben.

Der Zeitpunkt ist entscheidend. Wird eine zeitnahe Injektion erst erkannt, nachdem der Tool-Aufruf bereits vorbereitet wurde, kommt die Kontrolle zu spät. Wird die Schwärzung personenbezogener Daten erst durchgeführt, nachdem das Modell den Rohwert gesehen hat, werden lediglich die Transkripte maskiert. Erfolgt die Erkennung von Halluzinationen erst, nachdem die Antwort bereits gesendet wurde, handelt es sich lediglich um eine nachträgliche Protokollierung.

Ich würde die Regel also einfach halten: Eingabekontrollen werden vor der Planung ausgeführt, Ausgabekontrollen, bevor Daten das System verlassen. Das Gateway entscheidet, ob ein Tool-Aufruf das Kernbankensystem erreichen darf. Die Pipeline entscheidet, ob das Modell die richtigen Eingaben erhalten hat und ob seine Ausgabe sicher genug ist, um sie anzuzeigen, einen erneuten Versuch zu starten, zu blockieren, zu eskalieren oder zur Genehmigung weiterzuleiten.

Das Modell ohne Verwahrung: Der Beauftragte bereitet vor, führt aber niemals aus

Nach dem MCP-Gateway und der Safeguard-Pipeline gibt es noch eine weitere Regel, die ich in der Architektur ausdrücklich festhalten würde: Der Agent sollte keine Kontrolle über die jeweilige Aktion haben. Im Klartext bedeutet das: Er sollte nicht in der Lage sein, eigenständig Geld zu überweisen, einen Handel auszuführen, eine Auszahlung zu genehmigen oder einen regulierten Vorgang abzuschließen.

Das meine ich mit einem „Non-Custodial“-Modell. Der Mitarbeiter kann den nächsten Schritt vorbereiten, die Ausführung erfolgt jedoch außerhalb des Modells. Ein Übertragungs-Tool erstellt eine vorläufige Transaktion, die auf ihre Bestätigung wartet. Ein Börsen-Tool liefert einen Kurs, Gebühren, die Ablaufzeit und eine Bestätigungskarte. Ein Kartentool kann einen Sperrantrag vorbereiten. Ein KYC-Tool kann fehlende Daten erfassen und zur Überprüfung einreichen. In jedem Fall bereitet der Mitarbeiter den Vorgang vor, führt ihn aber nicht hinter den Kulissen aus.

AI banking workflow showing the agent prepares a transaction while execution stays with core banking.

Dieses Modell verändert die regulatorische Einordnung des Systems. Ein Agent, der Optionen erläutert, Hintergrundinformationen sammelt, Formulare vorbereitet und Anträge aufbereitet, lässt sich viel leichter als Ebene zur Entscheidungsunterstützung rechtfertigen. Ein Agent, der Finanztransaktionen eigenständig ausführt, wirkt hingegen zunehmend wie ein autonomer Finanzverwalter, was eine Reihe anderer Fragen hinsichtlich Zulassung, Haftung, Prüfung und Versicherung aufwirft.

Es gibt eine klarere Art zu erklären, warum diese Regel existiert. In dem Moment, in dem ein Akteur Wert über eine Organisationsgrenze hinweg überträgt, verhält er sich nicht mehr wie ein interner Koordinator, sondern wie ein wirtschaftlicher Akteur. Das ist die Klasse, die echte Haftung trägt, und genau die Klasse, die ein probabilistisches Modell nicht für sich allein abdecken soll. Indem man die Ausführung außerhalb des Modells belässt, verhindert man, dass ein Akteur unbemerkt in das Modell übergeht. Die Klassengrenze ergibt sich hier aus der Tatsache, dass Nicht jeder Akteur ist ein Wirtschaftsakteur..

Diese Unterscheidung ist entscheidend, wenn etwas schiefgeht. Bei einer nicht-verwahrenden Konfiguration können Sie nachweisen, was der Agent vorbereitet hat, welche Gateway-Prüfungen durchgeführt wurden, wer oder was die Aktion genehmigt hat und wann das Kernbankensystem sie ausgeführt hat. Ohne diese Trennung ist das Modell zu eng mit dem Geld verbunden. Ich würde einen Bankagenten nicht auf diese Weise konzipieren.

Technologieentscheidungen und warum sie wichtig sind

Ich füge den Abschnitt zum Stack aus einem Grund hinzu: Architekturversprechen sind billig, solange man nicht die Tools nennt, die diese Kontrollmechanismen tatsächlich umsetzen. Es ist leicht zu sagen: “Wir isolieren Mandanten”, “wir führen Checkpoints bei Workflows durch” oder “wir validieren Tool-Aufrufe”. Schwieriger ist es, einen Stack auszuwählen, bei dem diese Kontrollmechanismen nicht nur in Diagrammen und guten Absichten existieren. 

In einem Banking-Agent-System muss der Stack WebSocket-intensive Sitzungen, typisierte Finanzobjekte, wiederholbare Workflows, den Zugriff auf Standard-Tools, mandantenbezogene Speicherung und Laufzeitisolierung unterstützen. Wenn die Tools diesen Anforderungen zuwiderlaufen, entstehen in der Architektur nach und nach kleine, unscheinbare Risiken: eine fehlende `tenant_id`, eine typlose Tool-Nutzlast, ein Workflow-Status, der nur im Chat-Verlauf existiert, oder ein Konnektor, den niemand ordnungsgemäß prüfen kann.

Ich würde den Stack also unter einem einfachen Gesichtspunkt betrachten: Erleichtert diese Entscheidung später das Testen, Anhalten, Überprüfen, Wiederherstellen und Schützen des Systems? Wenn ja, gehört sie in die Diskussion. Wenn nicht, handelt es sich wahrscheinlich nur um eine Vorliebe des Entwicklers, die als Architektur getarnt ist.

Technologiewahl
Warum diese Wahl?
Kontrolle, die es bietet
Bankgeschäftlicher Grund
NestJS über Python
Die Agent-Schicht verarbeitet WebSocket-Sitzungen, BFF-Logik, Kanaladapter, typisierte Verträge und Finanzobjekte – nicht nur Modellaufrufe.
TypeScript-Typisierung für Mandanten-IDs, Guthaben, Begünstigte, Limits, Workflow-Zustände und Tool-Nutzdaten.
Bringt Client, BFF und Orchestrierung in einem Stack näher zusammen – mit LangChain.js und LangGraph.js.
LangGraph
Bankgeschäftsabläufe können verzweigt, unterbrochen, fortgesetzt und eskaliert werden.
Gerichtete Workflows, typisierter Zustand, bedingte Übergänge und PostgreSQL-Checkpoints.
Teams können den genauen Verlauf eines KYC-, Einspruchs-, Zahlungs- oder Bonitätsprüfungsablaufs einsehen.
MCP
Benutzerdefinierte Konnektoren erschweren die Verwaltung von Tool-Zugriffen, Berechtigungen und Überwachungsregeln.
Standardmäßige Tool-Erkennung, Tool-Beschreibungen, berechtigte Aufrufe und wiederverwendbare Skill-Schnittstellen.
Funktionen wie Auszahlungen, Onboarding, Kartenverwaltung, KYC-Nachbesserungen und Bonitätsprüfung ermöglichen den Zugriff auf genehmigte Funktionen, ohne dass ein direkter interner Zugriff erforderlich ist.
Aurora PostgreSQL + RLS
Die Isolierung von Mandanten sollte nicht ausschließlich von „tenant_id“-Filtern im Servicecode abhängen.
Mieterbezogene Speicherung für Workflows, Genehmigungen, Prüfprotokolle, Kontrollpunkte und finanzielle Metadaten.
RLS, Redis pro Mandant, gVisor oder Firecracker sowie separate Geheimnisspeicher verringern das Risiko von datenmandantenübergreifenden Informationslecks.

AI-Banking-Anfragen nachverfolgbar und kontrollierbar machen 

Mit Innowise können Sie festlegen, wer Anträge stellen, genehmigen und Maßnahmen ergreifen darf.

Was ich überprüfen würde, bevor ich einen Banking-Agenten als produktionsreif bezeichne

Bevor ich einen Banking-Agenten als einsatzbereit bezeichnen würde, würde ich versuchen, das MCP-Gateway absichtlich zum Absturz zu bringen: falscher Mandant, falsche Rolle, fehlerhafte Nutzdaten, fehlende Genehmigung, abgelaufenes Token, nicht verfügbarer Anbieter. Das Design ist erst dann ausgereift, wenn diese Fälle eindeutig fehlschlagen, eine Spur hinterlassen und keine Erläuterung des Modells erfordern, um zu erklären, was passiert ist.

Hier ist die Checkliste, die ich verwenden würde:

Prüfen Sie die
Was ich erwarten würde
RBAC auf Mandantenebene
Jedes Tool und jeder Endpunkt ist einem Mandanten, einer Benutzerrolle, einem Kanal und einem Workflow-Status zugeordnet
Vertragsüberprüfung
Tool-Aufrufe werden vor der Ausführung anhand genehmigter Schemata überprüft
Genehmigungsweg
Schwellenwertbasierte Warteschlangen für Zahlungen, neue Begünstigte, risikobehaftete Kontostatus und Ausnahmen von den Richtlinien
Ausführung ohne Verwahrung
Der Agent bereitet die Aktionen vor; der Benutzer, der Genehmiger oder die Policy-Engine bestätigt; das Kernbankensystem führt sie aus
Prüfpfad
Nur-Anhäng-Protokolle mit den Parametern „Mandant“, „Benutzer“, „Kanal“, „Tool“, „geschwärzte Daten“, „Genehmigungsstatus“, „Ergebnis“ und „Korrelations-ID“
Behandlung von Anbieterstörungen
Circuit Breaker, Wiederholungsregeln, Timeout-Verhalten und für Benutzer sichtbare Fallback-Meldungen
Gültigkeitsbereich des Tokens
Kurzlebige Tokens, die genau auf den jeweiligen Mandanten, die Kontoansicht, das Tool und den Workflow-Schritt beschränkt sind
Reaktions- und Handlungssteuerung
Überprüfung auf Halluzinationen und Einhaltung der Richtlinien, bevor die Antwort angezeigt oder die Aktion ausgeführt wird

An dieser Stelle würde ich den Test beenden: Kann die Bank jeden Schritt des Arbeitsablaufs rekonstruieren, begründen und unterbinden, ohne auf den Speicher des Modells oder die Erläuterungen eines Entwicklers zurückgreifen zu müssen? Wenn das MCP-Gateway diese Frage beantworten kann, hat die Architektur auch außerhalb des Demoraums eine echte Chance.

Mehr zu diesem Thema

    Kontakt aufnehmen

    Anruf vereinbaren oder füllen Sie das Formular aus. Wir kontaktieren Sie, sobald wir Ihre Anfrage bearbeitet haben.

    Sprachnachricht senden
    Datei beifügen
    Datei hochladen

    Sie können 1 Datei mit bis zu 2 MB anhängen. Gültige Dateiformate: pdf, jpg, jpeg, png.

    Mit dem Klicken auf Senden erklären Sie sich damit einverstanden, dass Innowise Ihre personenbezogenen Daten gemäß unserer Datenschutzerklärung verarbeitet, um Ihnen relevante Informationen bereitzustellen. Mit Angabe Ihrer Telefonnummer stimmen Sie zu, dass wir Sie per Sprachanruf, SMS oder Messaging-Apps kontaktieren. Es können Gebühren für Anrufe, Nachrichten und Datenübertragung anfallen.

    Sie können uns auch kontaktieren
    bis hin zu contact@innowise.com
    Wie geht es weiter?
    1

    Sobald wir Ihre Anfrage erhalten und geprüft haben, melden wir uns bei Ihnen, klären erste Fragen und unterzeichnen bei Bedarf ein NDA, um die Vertraulichkeit zu gewährleisten.

    2

    Nach genauer Prüfung Ihrer Anforderungen, Bedürfnisse und Erwartungen wird unser Team einen Projektvorschlag mit Angaben zu Arbeitsumfang, Teamgröße, Zeitaufwand und Kosten erstellen.

    3

    Wir vereinbaren einen Termin, um das Angebot gemeinsam zu besprechen und alle Details festzulegen.

    4

    Abschließend unterzeichnen wir den Vertrag und starten umgehend mit der Umsetzung Ihres Projekts.

    arrow