Ihre Nachricht wurde gesendet.
Wir werden Ihre Anfrage bearbeiten und uns so schnell wie möglich mit Ihnen in Verbindung setzen.
Das Formular wurde erfolgreich abgeschickt.
Weitere Informationen finden Sie in Ihrem Briefkasten.
Sprache auswählen
3. Juli 2026
10 Minuten Lesezeit

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.

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.
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:

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.
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.
Mit Innowise bleiben alle Vorgänge berechtigungsgebunden, nachvollziehbar und unter Ihrer Kontrolle.
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.
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.

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.
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.
Mit Innowise können Sie festlegen, wer Anträge stellen, genehmigen und Maßnahmen ergreifen darf.
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:
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.
Ihre Nachricht wurde gesendet.
Wir werden Ihre Anfrage bearbeiten und uns so schnell wie möglich mit Ihnen in Verbindung setzen.