KI‑Agenten sicher an das Core Banking anbinden

Ein KI-Agent ist dann sicher an ein Core-Banking-System angebunden, wenn er nie direkt auf das Kernbankensystem zugreift. Er nutzt nur eine kontrollierte API-Schicht mit eng definierten Werkzeugen, liest standardmässig nur und hat eine eigene Identität mit minimalen Rechten. Jede Aktion wird lückenlos protokolliert, und alles, was Daten verändert oder Geld bewegt, braucht eine menschliche Freigabe, bevor das System es ausführt.

Damit verschiebt sich die Frage für CIO, Leiter IT und COO: Über die Sicherheit entscheidet nicht das Sprachmodell, sondern die Architektur um das Modell herum. In diesem Beitrag zeigen wir, wie diese Architektur in fünf Schichten aussieht, was Sie vor der Produktionsfreigabe prüfen sollten und was FINMA, BaFin, Datenschutzrecht und EU AI Act für den Betrieb erwarten.

Kurz gesagt

• Kein Direktzugriff: Der Agent spricht nie mit der Datenbank des Kernbankensystems, sondern mit einer API-Schicht, die nur fachlich definierte Funktionen anbietet.
• Lesend zuerst: Lesender Zugriff ist der Standard. Schreibende Aktionen werden einzeln freigeschaltet, begrenzt und an eine menschliche Freigabe gebunden.
• Eigene Identität: Jeder Agent erhält eine eigene technische Identität mit minimalen, zeitlich begrenzten Berechtigungen, getrennt von den Rechten der Mitarbeitenden.
• Nachvollziehbarkeit: Jeder Werkzeugaufruf wird mit Auslöser, Parametern, Ergebnis und Freigabe protokolliert und lässt sich dem geänderten Datensatz zuordnen.
• Aufsicht: Die Verantwortung bleibt beim Institut. FINMA und BaFin erwarten Governance, Tests, Protokollierung und eine Kontrolle der Drittdienstleister.

Inhaltsverzeichnis

• Inhalt
• Warum die Anbindung der kritische Punkt ist
• Die Architektur in fünf Schichten
• Tool-Zugriff laut Claude-Dokumentation
• Schrittweise Umsetzung
• Checkliste vor der Freigabe
• Rolle der Aufsicht
• Unsere Sicht
• Wie S-PRO Banken bei der Anbindung unterstützt
• Häufige Fragen
• Quellen

Inhalt

1. Warum die Anbindung der kritische Punkt ist
2. Die Architektur in fünf Schichten
3. Tool-Zugriff laut Claude-Dokumentation
4. Schrittweise Umsetzung
5. Checkliste vor der Freigabe
6. Rolle der Aufsicht
7. Unsere Sicht
8. Wie S-PRO unterstützt
9. Häufige Fragen

Warum die Anbindung der kritische Punkt ist

An der Anbindung wird aus einem Assistenten ein handelndes System. Solange ein Agent nur Text erzeugt, bleibt ein Fehler ein falscher Satz. Greift er auf Kundenstammdaten, Konten oder Zahlungsfunktionen zu, kann ein Fehler einen Datensatz verändern.

Klassische API-Sicherheit reicht dafür nicht ganz aus. Das White Paper von Swiss Fintech Innovations zur Referenzarchitektur für den Agentenzugriff (Version 1.0, 26. Februar 2026) nennt neue Herausforderungen gegenüber klassischen API-Bedrohungen: das dynamische Verhalten von Agenten, Ketten aus mehreren Agenten, den Umgang mit Tokens und die Datenminimierung. Es hält zudem fest, dass es nicht genügt, bestehende APIs einfach für Agenten zu öffnen. Agenten brauchen mehr Kontext und Schnittstellen, die nach Fähigkeiten geschnitten sind und sie sicher führen.

In der Praxis sehen wir vier typische Risiken, auf die jede Architektur eine Antwort haben muss:

• Prompt Injection: Ein Dokument, eine E-Mail oder ein Feld in einer Kundennachricht enthält Anweisungen, die der Agent als Auftrag missversteht.
• Unbeabsichtigte Aktionen: Der Agent wählt das richtige Werkzeug mit falschen Parametern oder das falsche Werkzeug für die richtige Absicht.
• Zu breite Berechtigungen: Der Agent läuft mit einem Servicekonto, das weit mehr darf, als der Anwendungsfall braucht.
• Fehlende Rekonstruktion: Nach einem Vorfall lässt sich nicht mehr belegen, welcher Agent was auf wessen Veranlassung getan hat.

Keines dieser Risiken spricht gegen den Einsatz von Agenten im Kernbankenumfeld. Alle lassen sich mit Architektur, Berechtigungen und Prozessen beherrschen, und genau darum geht es in den folgenden Abschnitten.

Die Architektur in fünf Schichten

Eine sichere Anbindung trennt fünf Verantwortlichkeiten sauber voneinander: API-Schicht, Zugriffsart der Werkzeuge, Identität und Berechtigungen, Protokollierung sowie menschliche Freigabe. Jede Schicht fängt ab, was die vorherige durchlässt.

1. API-Schicht als einziger Zugang

Der Agent erreicht das Kernbankensystem ausschliesslich über eine API-Schicht zwischen Agent und Kernsystem. Diese Schicht bietet keine generischen Datenbankabfragen an, sondern fachliche Funktionen wie «Kontosaldo abrufen», «Kundenprofil lesen» oder «Zahlungsentwurf anlegen».

Das hat drei Vorteile. Erstens bleibt das Kernbankensystem unverändert, die Integration ersetzt nichts. Zweitens können Sie Eingaben prüfen, Mengen begrenzen und Felder maskieren, bevor Daten den Agenten erreichen. Drittens lässt sich der Zugang an einer Stelle abschalten. Das SFTI-White-Paper empfiehlt, neben klassischen APIs auch einen Zugang über das Model Context Protocol (MCP) anzubieten. Bestehende API-Spezifikationen und Consent-Modelle sollen dafür eine feingranulare Autorisierung nach Fähigkeiten erhalten.

2. Lesender statt schreibender Zugriff

Die wichtigste Designentscheidung ist die Zugriffsart je Werkzeug. Jeder Anwendungsfall beginnt mit lesendem Zugriff. Schreibender Zugriff wird nicht pauschal gewährt, sondern pro Funktion, mit Obergrenzen und meist als Entwurf, den ein Mensch bestätigt.

Ein bewährtes Muster: Der Agent bereitet vor, der Mensch entscheidet, das Kernsystem führt aus. Der Agent schreibt also nicht ins Hauptbuch, sondern legt einen Entwurf in einer Warteschlange ab.

3. Identität und Berechtigungen

Jeder Agent bekommt eine eigene technische Identität, die im Identity- und Access-Management wie ein privilegiertes Konto behandelt wird. Sie erhält nur die Berechtigungen, die der konkrete Anwendungsfall braucht, und wird mit niemandem geteilt, auch nicht mit dem Konto eines Mitarbeitenden.

Handelt der Agent im Auftrag einer Person, etwa eines Kundenberaters, dürfen seine Rechte nie über die Rechte dieser Person hinausgehen. Dazu gehören kurzlebige Tokens, eingeschränkte Scopes und getrennte Identitäten für Test und Produktion. Für die Autorisierung lohnt es sich, auf etablierte Standards zu setzen: Laut dem SFTI Common API Update Q1 2026 wird der Consent Flow 3.0 FAPI-2.0-konform spezifiziert, mit PKCE und PAR und ohne proprietäre Berechtigungsmodelle.

4. Protokollierung und Überwachung

Jeder Werkzeugaufruf erzeugt einen Protokolleintrag, der fünf Fragen beantwortet: welcher Agent, auf wessen Veranlassung, mit welchen Parametern, mit welchem Ergebnis und mit wessen Freigabe. Bei schreibenden Aktionen kommt der Bezug zum geänderten Datensatz hinzu.

Die Protokolle müssen nicht nur vorhanden, sondern auch auswertbar sein. Die Überwachung erkennt ungewöhnliche Muster, etwa eine plötzliche Häufung von Abfragen, Zugriffe ausserhalb des üblichen Datenbereichs oder wiederholt abgelehnte Aufrufe. Zudem sollten Prompts, Werkzeugdefinitionen und Modellversionen versioniert sein, damit sich jedes Verhalten einem bestimmten Stand zuordnen lässt.

5. Menschliche Freigabe

Die menschliche Freigabe ist die letzte Kontrolle, bevor etwas im Kernsystem wirkt. Sie wird nach Risiko gestaffelt: Eine Fallnotiz braucht keine Vier-Augen-Prüfung, eine Zahlung oder eine Änderung von Stammdaten schon.

Die freigebende Person sieht nicht nur den Vorschlag, sondern auch die Begründung und die Daten, auf die sich der Agent stützt. Dazu braucht es einen getesteten Notschalter, der den Agenten stoppt, ohne den übrigen Bankbetrieb zu beeinträchtigen. So bleibt die Entscheidung dort, wo die Verantwortung liegt.

Tool-Zugriff laut Claude-Dokumentation

Bei Claude führt das Modell Werkzeuge nicht selbst aus: Es schlägt einen Werkzeugaufruf vor, und Ihre Anwendung entscheidet, ob und wie er ausgeführt wird. Für die Anbindung an ein Kernbankensystem ist das die entscheidende Eigenschaft.

Laut der Claude-Dokumentation zur Tool-Nutzung definieren Sie jedes Werkzeug mit einem Namen, einer Beschreibung und einem Eingabeschema im Format JSON Schema. Will das Modell ein Werkzeug nutzen, antwortet es mit einem strukturierten Aufruf. Ihre Anwendung führt die Funktion aus und gibt das Ergebnis zurück.

Für die fünf Schichten heisst das konkret:

• Das Eingabeschema ist Ihre erste Prüfung. Enge Typen, Pflichtfelder und erlaubte Werte verhindern viele falsche Parameter.
• Zwischen Vorschlag und Ausführung liegt Ihr Code. Dort prüfen Sie Berechtigungen, schreiben das Protokoll und holen bei schreibenden Aktionen die Freigabe ein.
• Nur definierte Werkzeuge sind erreichbar. Was nicht als Werkzeug beschrieben ist, kann der Agent nicht aufrufen.
• Beschreibungen steuern das Verhalten. Klare Angaben, wann ein Werkzeug zu nutzen ist und wann nicht, helfen dem Modell bei der richtigen Wahl.

Dasselbe Prinzip gilt, wenn Sie Werkzeuge über einen MCP-Server bereitstellen: Der Server gehört zu Ihrer API-Schicht und folgt denselben Regeln für Identität, Protokollierung und Freigabe.

Schrittweise Umsetzung

Die Anbindung gelingt am besten in kleinen, überprüfbaren Schritten, vom lesenden Pilot bis zu begrenzten schreibenden Aktionen. So wächst das Vertrauen in den Agenten mit den Belegen aus dem Betrieb.

1. Anwendungsfall eingrenzen: Wählen Sie einen Prozess mit klarem Nutzen und begrenztem Datenbereich, etwa die Vorbereitung von Kundengesprächen oder die Recherche in Transaktionshistorien.
2. Werkzeuge fachlich schneiden: Definieren Sie wenige, eng beschriebene Funktionen in der API-Schicht, zunächst nur lesend.
3. Identität und Berechtigungen einrichten: Legen Sie die technische Identität des Agenten mit minimalen Scopes an und trennen Sie Test und Produktion.
4. Protokollierung vor dem ersten Aufruf: Aktivieren Sie Audit-Log und Überwachung, bevor der Agent produktive Daten sieht.
5. Mit Testfällen prüfen: Testen Sie typische Anfragen, Grenzfälle und gezielte Manipulationsversuche wie eingeschleuste Anweisungen in Dokumenten.
6. Schreibende Aktionen einzeln freischalten: Ergänzen Sie schreibende Funktionen als Entwürfe mit Freigabe, Obergrenzen und definiertem Korrekturweg.
7. An den Betrieb übergeben: Verankern Sie Zuständigkeiten, den Änderungsprozess für Prompts und Werkzeuge sowie den Notschalter im regulären IT-Betrieb.

Sie möchten einen Agenten an Ihr Kernbankensystem anbinden, aber offene Fragen zu Berechtigungen, Protokollierung und Freigaben blockieren das Projekt? Besprechen Sie Ihre Architektur mit unseren Engineers.

Checkliste vor der Freigabe

Bevor ein Agent produktiv auf Kernbankendaten zugreift, sollten Sie jeden der folgenden Punkte mit Ja beantworten können. Die Liste ist bewusst kurz und prüfbar, damit IT, Risikomanagement und Fachbereich sie gemeinsam abzeichnen können.

1. Der Agent greift ausschliesslich über die API-Schicht zu, ein Direktzugriff auf die Datenbank ist technisch ausgeschlossen.
2. Für jedes Werkzeug ist dokumentiert, ob es lesend oder schreibend ist, welche Daten es liefert und welche Obergrenzen gelten.
3. Der Agent hat eine eigene technische Identität mit minimalen, zeitlich begrenzten Berechtigungen.
4. Sensible Felder werden maskiert oder weggelassen, wenn der Anwendungsfall sie nicht braucht.
5. Jeder Werkzeugaufruf wird mit Auslöser, Parametern, Ergebnis und Freigabe protokolliert, und die Protokolle sind auswertbar.
6. Schreibende Aktionen brauchen eine menschliche Freigabe nach definierten Risikoschwellen.
7. Es gibt einen getesteten Weg, den Agenten zu stoppen und seine Aktionen zu korrigieren.
8. Prompts, Werkzeugdefinitionen und Modellversionen sind versioniert und unterliegen einem Änderungsprozess.
9. Manipulationsversuche wie Prompt Injection wurden getestet und die Ergebnisse dokumentiert.
10. Der Anwendungsfall ist im KI-Inventar erfasst, mit Risikoklassifizierung und einer benannten verantwortlichen Person.
11. Die Verträge mit Modell- und Cloud-Anbietern sind geprüft, einschliesslich Datenstandort und Auslagerungsvorgaben.
12. Kundinnen und Kunden werden informiert, wo das Datenschutzrecht dies verlangt.

Rolle der Aufsicht

Die Aufsicht verlangt keine eigene KI-Bewilligung. Sie erwartet aber, dass ein Agent in die bestehende Governance, das Risikomanagement und die Kontrolle der Drittdienstleister eingebettet ist. Die Verantwortung für jede Agentenaktion bleibt beim Institut und seinen Organen.

Dieser Abschnitt ist keine Rechtsberatung. Für die Einordnung Ihres konkreten Anwendungsfalls sollten Sie Compliance, Rechtsdienst und gegebenenfalls Ihre Prüfgesellschaft einbeziehen.

FINMA

Die FINMA hat am 18. Dezember 2024 die Aufsichtsmitteilung 08/2024 «Governance und Risikomanagement beim Einsatz Künstlicher Intelligenz» veröffentlicht. Laut einer Zusammenfassung der Aufsichtsmitteilung erwartet die FINMA klare Verantwortlichkeiten, Vorgaben zur Datenqualität, Tests und laufende Überwachung sowie erklärbare Ergebnisse. Hinzu kommen eine unabhängige Überprüfung wesentlicher Anwendungen und ein Inventar mit Risikoklassifizierung.

Dazu kommt das FINMA-Rundschreiben 2023/1 «Operationelle Risiken und Resilienz – Banken», seit 1. Januar 2024 in Kraft. Es verlangt unter anderem, kritische Daten und inventarisierte IKT-Komponenten zu schützen und Cyber-Risiken auf Basis eines international anerkannten Standards zu steuern. Eine API-Schicht mit Protokollierung und Notschalter unterstützt diese Anforderungen direkt.

BaFin

Für Institute in Deutschland hat die BaFin am 18. Dezember 2025 eine Orientierungshilfe zu IKT-Risiken beim Einsatz von KI veröffentlicht. Für die Anbindung an das Kernbankensystem zählen vor allem drei Themen: die Einbettung von KI in die Betriebsprozesse, die Protokollierung und die Steuerung von Drittdienstleistern, etwa Modell- und Cloud-Anbietern. Schweizer Gruppen mit zugelassener EU-Tochter sollten zudem beachten, dass für diese Tochter die DORA-Verordnung (EU) 2022/2554 gilt, die seit 17. Januar 2025 anwendbar ist.

Datenschutz: DSG

Das revidierte Datenschutzgesetz ist seit 1. September 2023 in Kraft. Der EDÖB hat am 9. November 2023 bestätigt, dass es direkt auf KI-gestützte Datenbearbeitung anwendbar ist. Zweck, Funktionsweise und Datenquellen müssen transparent sein. Trifft ein System eine Entscheidung ausschliesslich automatisiert und beeinträchtigt sie Betroffene erheblich, verlangt Art. 21 DSG, dass die Betroffenen informiert werden und auf Wunsch eine Überprüfung durch einen Menschen erhalten. Die Freigabeschicht deckt diesen Punkt in der Architektur ab.

EU AI Act

Für Institute mit Geschäft in der EU gilt der EU AI Act. Massgeblich für die Termine ist die Verordnung (EU) 2026/1744 (KI-Omnibus), seit 27. Juli 2026 in Kraft. Der allgemeine Anwendungstermin war der 2. August 2026. Die Pflichten für Hochrisiko-Systeme nach Anhang III, zu denen etwa die Kreditwürdigkeitsprüfung natürlicher Personen gehört, gelten ab 2. Dezember 2027. Die Pflichten nach Artikel 6 Absatz 1 und Anhang I gelten ab 2. August 2028.

Unsere Sicht

In vielen Gesprächen mit Banken sehen wir dasselbe Muster: Die Diskussion beginnt beim Modell und endet bei der Integration. Dabei entscheidet gerade die Integration darüber, ob ein Agent je produktiv wird.

Sichere Agenten im Kernbankenumfeld sind für uns keine Frage von Mut, sondern von Disziplin. Wer mit lesendem Zugriff beginnt, Werkzeuge fachlich schneidet und Protokollierung sowie Freigabe von Anfang an einplant, kommt schneller in die Produktion als jemand, der diese Fragen erst am Ende klärt.

Deshalb bauen wir jede Kundenlösung auf unserer eigenen agentischen Plattform S-PRO Agents auf und betreiben sie als Service. So muss nicht jede Bank die Grundlagen für Identität, Protokollierung und Freigabe neu erfinden, und die Fachlogik des Instituts steht im Mittelpunkt.

Das bestehende Kernbankensystem bleibt dabei, was es ist: das führende System. Der Agent arbeitet daneben, nicht darin.

Das S-PRO-Team

Wie S-PRO Banken bei der Anbindung unterstützt

S-PRO entwickelt KI-Agenten für Banken, Vermögensverwalter und Fintechs und bindet sie über kontrollierte Schnittstellen an bestehende Systeme an, ohne das Kernbankensystem zu ersetzen. Unsere Engineers planen API-Schicht, Berechtigungen, Protokollierung und Freigaben gemeinsam mit Ihrer IT, Ihrem Risikomanagement und Ihrer Compliance.

Unser Hauptsitz ist in Zürich an der Löwenstrasse 45, 8001 Zürich. Unsere R&D-Zentren liegen in Zürich und Łódź. S-PRO wurde 2014 gegründet, beschäftigt mehr als 250 Ingenieure und ist nach ISO 27001 und ISO 27701 zertifiziert. S-PRO ist Partner im Claude Partner Network, und unser Team umfasst Claude-zertifizierte Engineers und Architects. Unsere Lösungen sind im Hinblick auf die Anforderungen von EU AI Act, FINMA und DORA konzipiert.

Wie wir dabei vorgehen, zeigen wir auf der Seite zur Entwicklung von KI-Agenten für Banken.

Sie planen die Anbindung eines Agenten an Ihr Kernbankensystem? Vereinbaren Sie ein Erstgespräch mit S-PRO.

Häufige Fragen

Muss das Kernbankensystem für einen KI-Agenten ersetzt werden?

Nein. Der Agent greift über eine API-Schicht auf fachlich definierte Funktionen zu, das Kernbankensystem bleibt das führende System und wird nicht verändert. Die Integration ergänzt also die bestehende Landschaft. Voraussetzung ist, dass die benötigten Daten und Funktionen über Schnittstellen erreichbar sind oder sich über eine Zwischenschicht erschliessen lassen, die Prüfung, Maskierung und Protokollierung übernimmt.

Darf ein KI-Agent schreibend auf Kernbankendaten zugreifen?

Ja, aber nur einzeln freigeschaltet, begrenzt und in der Regel mit menschlicher Freigabe. Bewährt hat sich ein Muster, bei dem der Agent einen Entwurf vorbereitet, eine berechtigte Person entscheidet und das Kernsystem ausführt. Jede schreibende Aktion wird mit dem Zustand vorher und nachher sowie der freigebenden Person protokolliert und hat einen definierten Korrekturweg.

Braucht es eine FINMA-Bewilligung für KI-Agenten?

Eine eigene KI-Bewilligung gibt es in der Schweiz nicht. Die FINMA erwartet jedoch, dass KI-Anwendungen in Governance, Risikomanagement und die Kontrolle der Drittdienstleister eingebettet sind, wie es die Aufsichtsmitteilung 08/2024 beschreibt. Die Verantwortung für die Aktionen eines Agenten bleibt beim Institut. Für die Einordnung Ihres Falls sollten Sie Compliance und Rechtsdienst früh einbeziehen.

Wie lange dauert ein Pilot und was kostet er?

Für den Einstieg bietet S-PRO einen Design-Thinking-Pilot ab CHF 20k, 2-4 Wochen. In dieser Phase klären wir mit Ihnen Anwendungsfall, Datenbereich, Werkzeuge und Kontrollen und zeigen den Weg in die Produktion auf. Es ist sinnvoll, im Pilot mit lesendem Zugriff zu beginnen und schreibende Aktionen erst danach einzeln zu ergänzen.

Welche Rolle spielt das Model Context Protocol?

MCP ist ein offener Standard, über den Agenten strukturiert mit Diensten und Werkzeugen arbeiten. Swiss Fintech Innovations empfiehlt Finanzinstituten, neben klassischen APIs auch einen MCP-Zugang anzubieten und die Autorisierung feingranular nach Fähigkeiten zu gestalten. Ein MCP-Server gehört zur API-Schicht und folgt denselben Regeln für Identität, Protokollierung und Freigabe.

Quellen

• Swiss Fintech Innovations: Reference Architecture for AI Agent Access to SFTI APIs (26.02.2026)
• Swiss Fintech Innovations: SFTI Common API Update Q1 2026
• Anthropic: Claude-Dokumentation zur Tool-Nutzung
• advoro: Einsatz von KI bei Finanzinstituten, Fokus auf Governance und Risk Management
• FINMA-Rundschreiben 2023/1 Operationelle Risiken und Resilienz – Banken (in Kraft seit 01.01.2024)
• EDÖB: Geltendes Datenschutzgesetz ist auf KI direkt anwendbar (09.11.2023)
• Fedlex: Bundesgesetz über den Datenschutz (DSG)
• EUR-Lex: Verordnung (EU) 2026/1744 (KI-Omnibus)
• EUR-Lex: Verordnung (EU) 2022/2554 (DORA)

Zuletzt aktualisiert: 5. November 2026

Empfehlungen

• Agentic Banking: Anwendungsfälle für KI-Agenten in Schweizer und deutschen Banken
• 6 Produktionsgates für KI-Agenten in Banken (2026)
• Kernbankensystem-Integration: Compliance und Strategien
• KI-Agenten Entwicklung für Banken in der Schweiz