SAFR erklärt: das Laufzeit-Framework der MAS für KI-Agenten im Finanzsektor

Warum es SAFR gibt¶

Finanzinstitute setzen KI-Agenten ein, die handeln. Sie lösen Zahlungen aus, erteilen Handelsaufträge, genehmigen Kreditanträge, reichen aufsichtliche Meldungen ein und regulieren Versicherungsschäden, oft in hoher Frequenz und ohne dass ein Mensch jede einzelne Aktion prüft. Das Papier nennt fünf Anwendungsfelder mit erhöhtem Governance-Bedarf: Zahlungsverkehr, Liquiditätsmanagement, Compliance-Triage, Kreditwürdigkeitsprüfung und Nachbearbeitung von Transaktionen.

Hinzu kommt eine systemische Dimension. Wenn viele Institute auf wenige gemeinsame KI-Dienstleister setzen, können sich ihre Agenten gleichgerichtet verhalten. Das Financial Stability Board hat diese Korrelation als mögliche systemische Schwachstelle benannt.

Vor diesem Hintergrund benennt SAFR drei Lücken in der Governance-Infrastruktur, die Institute bereits betreiben.

Lücke 1: Absicherung vor der Ausführung. Das Modellrisikomanagement validiert ein System vor dem Einsatz. Die Revision untersucht im Nachhinein, was geschehen ist. Keine der beiden Disziplinen fängt eine problematische Agentenentscheidung in dem Moment ab, bevor sie ausgeführt wird.

Lücke 2: die Schnittstelle zwischen Mensch und Agent. Die Eskalation an einen Menschen erfolgt heute ad hoc (eine Benachrichtigung, eine E-Mail, ein Hinweis im Dashboard), ohne Frist, ohne einheitliches Entscheidungsformat und ohne Prüfnachweis. Das Papier nennt das den Anschein menschlicher Aufsicht ohne deren Substanz.

Lücke 3: Fragmentierung. Jeder Einsatz baut eigene Guardrails. Die Ergebnisse sind nicht interoperabel und lassen sich nicht institutsweit in einem einheitlichen Format prüfen.

SAFR ist ein Lösungsvorschlag für alle drei: ein ständiger Kontrollpunkt im Ausführungspfad, ein strukturierter Eskalationsvertrag mit Fristen und Entscheidungsnachweisen und ein einheitliches Governance-Format für alle Agenten.

Was ist SAFR?¶

Nach dem Papier definiert SAFR Datenstrukturen, Bewertungslogik und Eskalationsverträge für den Einsatz agentischer KI. Es sitzt zwischen dem Agenten und den Systemen, auf die er einwirkt, bewertet vorgeschlagene Aktionen vor der Ausführung und arbeitet dabei mit bestehenden Zahlungsverkehrsinfrastrukturen, Abwicklungsprotokollen, Compliance-Engines und Kernbankensystemen zusammen.

Für Leser mit Compliance-Auftrag sind drei Abgrenzungen wichtig.

Erstens hat SAFR keine aufsichtliche Verbindlichkeit. Version 1.1 sagt ausdrücklich, dass SAFR keine regulatorische Leitlinie und keine aufsichtlichen Erwartungen darstellt und künftige Ausrichtungen solcher Leitlinien oder Erwartungen weder vorgibt noch vorwegnimmt. Jedes Institut bleibt dafür verantwortlich, festzustellen, wie sein eigener Einsatz mit den geltenden aufsichtlichen Erwartungen und internen Governance-Anforderungen übereinstimmt.

Zweitens ist SAFR eine Spezifikation, nach der Institute selbst bauen. Es dient als Branchenreferenz, die Institute in ihrer eigenen Infrastruktur mit eigenen Regelkonfigurationen und Governance-Regelungen umsetzen. Einen von der MAS betriebenen SAFR-Dienst, den man abonnieren könnte, gibt es nicht.

Drittens beschränkt sich SAFR auf die Laufzeitentscheidung. Es legt fest, wie eine vorgeschlagene Aktion im Moment des Handelns identifiziert, autorisiert, bewertet und aufgezeichnet wird. Modellvalidierung, Lebenszyklusmanagement und umfassendere KI-Risiko-Frameworks liegen darum herum (mehr zu diesem Umfeld weiter unten).

Der Status von SAFR im Oktober 2026¶

In derselben Woche erschienen zwei Dokumente. Am 7. Oktober 2026 veröffentlichte die MAS ihre finalen Guidelines on Artificial Intelligence Risk Management (AIRG). Sie gelten ab dem 7. Oktober 2027, beziehen KI-Agenten ausdrücklich ein und verlangen die Lebenszykluskontrollen bis zum 7. Oktober 2028. Am 9. Oktober 2026 veröffentlichte BuildFin.ai SAFR Version 1.1.

Die Leitlinien erwähnen SAFR nicht, und Version 1.1 stellt fest, dass SAFR künftige Ausrichtungen regulatorischer Leitlinien oder aufsichtlicher Erwartungen weder vorgibt noch vorwegnimmt. Die MAS hat sich nicht verpflichtet, SAFR verbindlich zu machen. Als nächsten Schritt zu Agenten kündigt sie für 2027 eine Konsultation dazu an, welche zusätzlichen Leitlinien zu agentischer KI hilfreich wären. SAFR ist eine freiwillige Referenz, und die AIRG sind das Dokument, an dem die MAS ihre Aufsicht ausrichtet.

In der Praxis greifen beide trotzdem ineinander. Die AIRG verlangen von Finanzinstituten, Prüfern die notwendige Befugnis und Fähigkeit zum Eingreifen zu geben, Ergebnisse zur menschlichen Prüfung zu eskalieren, wenn vorab festgelegte Bedingungen erfüllt sind, und, wo relevant, ausgeführte Aktionen und verwendete Tools zu überwachen. Ein Kontrollpunkt nach SAFR-Muster erzeugt genau diese Nachweise für jede Agentenaktion. Die Fristen und die agentenspezifischen Passagen behandelt der Beitrag Die MAS-Leitlinien zum KI-Risikomanagement sind final.

Die vier SAFR-Laufzeitkomponenten¶

Die Architektur von SAFR besteht aus vier Komponenten, die über eine gemeinsame Datenstruktur zusammenwirken, den Governance Envelope. Jede Komponente beantwortet eine Frage zu einer vorgeschlagenen Aktion.

Agent Identity bindet jede vorgeschlagene Aktion an einen bekannten, registrierten Agenten und prüft sie gegen dessen Registereintrag, bevor eine andere Bewertung beginnt. In einer geschlossenen Umgebung genügt ein direkter Abgleich mit dem eigenen Register des Instituts. In offenen Netzen kann ein Agent in mehreren Identitätsdatenbanken registriert sein (im internen Register des Instituts, im Agentenregister eines Zahlungsnetzwerks, in einem institutsübergreifenden Verzeichnis), und die Komponente bestimmt, welches Register für die jeweilige Aktion maßgeblich ist. Eine fehlgeschlagene Identitätsprüfung führt zur sofortigen Ablehnung, die im Audit Log festgehalten wird.

Im Controls Repository hinterlegt das Institut seine Regeln. Die Kontrollen stammen aus Unternehmensrichtlinien, regulatorischen Anforderungen, Produktregeln sowie aus Mandaten oder Befugnissen, die Nutzer erteilt haben. Allgemeine Kontrollen wie Berechtigungsprüfungen und Exposure-Limits sind deterministisch. KI-spezifische Kontrollen wie Evidenzqualität und Integrität des Envelope können probabilistische oder semantische Bewertungen umfassen. Jede Kontrolle legt fünf Dinge fest: die zulässigen Aktionstypen, die Entscheidungslogik, die Eskalationsbedingungen, eine Gültigkeitsdauer und die übergeordnete Befugnis, auf der sie beruht.

Die Disposition Engine bewertet jede Aktion im Anwendungsbereich deterministisch gegen die abgerufenen Kontrollen und liefert für jede vorgeschlagene folgenreiche Aktion ein definiertes, verbindliches Ergebnis, das auf das konkrete Risiko kalibriert ist. Die vier möglichen Ergebnisse werden unten ausführlich beschrieben.

Das Audit Log zeichnet jede Governance-Entscheidung manipulationssicher und nur anfügend (append-only) auf. Jeder Eintrag erfasst sechs Elemente: den eingereichten Governance Envelope, das Mandat, gegen das die Aktion geprüft wurde, das Ergebnis der Disposition Engine, die angewandten Regeln, die Begründung des Ergebnisses und die in jeder Phase verstrichene Zeit. Nach dem Papier ist das Log der maßgebliche Nachweis, unabhängig von jeder Partei, die ein Interesse daran hat, wie die Ereignisse im Nachhinein dargestellt werden.

Der Ablauf verbindet die vier Komponenten. Eine vorgeschlagene Aktion wird in einen Governance Envelope gepackt und auf Vollständigkeit und Stimmigkeit geprüft. Agent Identity wird gegen das maßgebliche Register verifiziert; scheitert die Prüfung, wird die Aktion sofort abgelehnt und protokolliert. Das Controls Repository bestimmt, welche Kontrollen zu prüfen sind. Die Disposition Engine ermittelt die anwendbaren Schwellenwerte und liefert eines von vier Ergebnissen. Das Audit Log zeichnet für jedes Ergebnis die vollständige Governance-Spur auf, auch für Aktionen, die ohne Eingriff ausgeführt wurden.

Der Governance Envelope¶

Bevor eine agentische Aktion ausgeführt wird, wird sie mit dem Kontext gebündelt, der für ihre Bewertung nötig ist. Der Envelope enthält drei Klassen von Informationen.

Der Envelope hat ein Integritätsproblem, das das Papier offen anspricht. Aktionsspur und Aktionsdetails werden beide vom Agenten selbst deklariert. Eine ausgefeilte gegnerische Injektion könnte also beides zugleich fälschen: eine plausibel wirkende Spur um eine nicht autorisierte Aktion. Version 1.1 benennt die Folge klar: Der Governance Envelope sollte nicht als selbstverifizierend behandelt werden. Wo möglich, sollten die vom Agenten gelieferten Felder daher gegen Aufzeichnungen geprüft werden, die unabhängig vom Agenten erfasst wurden, etwa die auslösende Anweisung, die tatsächliche Aktionsnutzlast und systemseitig erzeugte Aufzeichnungen von Tool-Aufrufen und Datenzugriffen, und der Envelope sollte an den verifizierten Agenten, die Sitzung und das anwendbare Mandat gebunden und gegen spätere Veränderung geschützt sein. Implementierungen brauchen einen Weg, an der Quelle zu prüfen, dass der Envelope wiedergibt, was tatsächlich geschehen ist.

Mandate und fähigkeitsbasierte Befugnisse¶

Ein Mandat ist nach SAFR der Mechanismus, mit dem delegierte Befugnisse abgegrenzt und in maschinenlesbarer Form ausgedrückt werden. Wenn ein Prinzipal einen Agenten ermächtigt, in seinem Namen zu handeln, hält das Mandat diese Delegation ausdrücklich fest: was der Agent tun darf, in welchen Grenzen und unter welchen Bedingungen.

Das Design stützt sich auf fähigkeitsbasierte Sicherheit (capability-based security), eine Tradition, die das Papier auf die Arbeit von Dennis und Van Horn aus dem Jahr 1966 zurückführt und auf der auch OAuth 2.0 beruht. Die tragende Eigenschaft: Ein Agent kann den Umfang eines Mandats nicht durch eigenes Schlussfolgern erweitern. Befugnis ist explizit, strukturiert und durch das Mandat definiert und wird nicht vom Agenten abgeleitet. Wie überzeugend ein Agent auch begründet, warum er seine Grenzen überschreiten sollte: Das Mandat ist die Grenze.

Als prominentes Branchenbeispiel nennt das Papier das Agent Payments Protocol (AP2) mit kryptografisch signierten Mandaten.

Die vier SAFR-Dispositionen: Deny, Escalate, Auto-Execute, Observe¶

Die Disposition Engine ordnet jeder Aktion im Anwendungsbereich eines von vier Ergebnissen zu. Alle vier fließen in das Audit Log ein.

Mit Observe kann ein Institut risikoarme Automatisierung laufen lassen und zugleich einen prüfbaren Nachweis der Fälle aufbauen, die es sich später ansehen will.

Welche Disposition eine Aktion erhält, ist eine Frage der Kalibrierung und wird zur Entwurfszeit über die Governance-Parameter der Kontrollen festgelegt. Das Papier nennt fünf Kalibrierungsfaktoren: Umkehrbarkeit der Aktion, finanzielle Wesentlichkeit, Schwere der Auswirkung auf Kunden, regulatorische Sensibilität sowie Neuartigkeit oder Anomalie, also die Abweichung von etablierten Mustern innerhalb des Mandats. Höhere Risikoprofile verschieben die Ergebnisse in Richtung Deny oder Escalate.

Keine Befugnis wird von Schritt zu Schritt übertragen¶

Agentische Prozesse bestehen selten aus einer einzigen Aktion. Ein Agent reichert Daten an, ruft Tools auf, reagiert auf Zwischenergebnisse und schlägt seinen nächsten Schritt auf Grundlage dessen vor, was er gerade erfahren hat. SAFR antwortet darauf mit Governance pro Aktion: Der Kontrollablauf gilt für jede Agentenaktion einzeln.

Das Papier formuliert die Konsequenz genau: Ein Ergebnis Auto-Execute oder Observe in einem Schritt überträgt keine Befugnis auf den nächsten. Eine frühere Autorisierung gilt nicht fort, wenn der Agent sich an Zwischenergebnisse und veränderte Bedingungen anpasst. Schritt drei eines Workflows durchläuft dieselbe Identitätsprüfung, denselben Kontrollabruf und dieselbe Disposition wie Schritt eins. Für Institute schließt das den Fall aus, dass ein Agent früh eine Freigabe erhält und dann, formal „autorisiert“, in Bereiche abdriftet, die niemand geprüft hat.

Die beiden SAFR-Bereitstellungsmuster¶

SAFR beschreibt zwei Wege, den Kontrollpunkt in die Systemlandschaft eines Instituts einzubauen.

Für Institute, die bereits Agenten betreiben, gibt das Papier eine Reihenfolge vor: Für Institute mit vielen bestehenden Agenten ist das Gateway-Muster ein praktischer Ausgangspunkt, weil es zuerst Abdeckung herstellt; die native Instrumentierung kann für Neuentwicklungen folgen. Erst Abdeckung, dann Tiefe.

Was Institute konfigurieren: die vier Kontrollkategorien¶

SAFR überlässt das Regelwerk dem Institut. Tabelle 1 des Papiers definiert vier Kategorien von Kontrollen, die eine Implementierung unterstützen sollte.

Zwei Gestaltungshinweise des Papiers fallen auf. Exposure-Limits sollten die Kompetenzordnungen abbilden, die das Institut bereits für Menschen betreibt, damit sich die Befugnisse von Agenten in ein bestehendes Governance-Vokabular einfügen. Und die Evidenzqualität wirkt unabhängig vom Betrag: Eine Aktion mit geringer Konfidenz geht an einen Menschen, auch wenn der Betrag unbedeutend ist.

Den Eskalationspfad betreiben¶

Eine Disposition Escalate ist nur so gut wie der menschliche Prüfprozess dahinter. SAFR nennt drei betriebliche Dimensionen, die Institute bewusst gestalten müssen.

Eskalationsvolumen. Eine Eskalationsfunktion, die mehr Prüfungen erzeugt, als das Institut sinnvoll bearbeiten kann, verfehlt ihren Zweck. Die Schwellenwerte müssen an der tatsächlichen Prüfkapazität ausgerichtet werden.

Bearbeitungszeit. Eskalationen sollten ein Zeitfenster haben. Trifft innerhalb dieses Fensters keine Entscheidung ein, wird die Aktion standardmäßig blockiert oder an einen höherrangigen Prüfer eskaliert. Das Fenster sollte die realistische Verfügbarkeit der Prüfer abbilden, einschließlich nachts und am Wochenende.

Befugnis der Prüfer. Prüfer brauchen die klare Befugnis, die Aktion zu genehmigen, zu ändern oder abzulehnen, und ihre Entscheidungen haben dasselbe institutionelle Gewicht wie die ursprüngliche Agentenentscheidung. Ein Prüfer, der nur abnicken kann, reproduziert die Lücke, die SAFR schließen will.

Befugnisse müssen außerdem erkennbar sein. Als wir erstmals AML-Fälle als Compliance-Nutzer durch unsere eigenen Test-Tenants laufen ließen, konnte ein Prüfer einen eskalierten Fall öffnen und sah ihn als „nur Ansicht“ markiert, ohne Begründung. Decision Desk nennt jetzt den Grund, warum eine Person nicht entscheiden kann: eine fehlende Berechtigung, keine Mitgliedschaft in der Genehmigergruppe oder die eigene Rolle als Ersteller der Anfrage. Eine Vier-Augen-Trennung, die der Prüfer nicht sehen kann, wirkt wie ein defektes Werkzeug.

Wo SAFR im Stack sitzt¶

SAFR lässt sich gut als Schicht mit klar definierten Nachbarn lesen. Der Ablauf: Der KI-Agent erzeugt eine vorgeschlagene Aktion (seine Guardrails können die Ausgabe formen); SAFR prüft Identität und Befugnis des Agenten und bewertet die Aktion deterministisch gegen die Kontrollen, mit dem Ergebnis Auto-Execute, Observe, Escalate oder Deny; die Finanzinfrastruktur führt die Aktion genau dann aus, wenn sie freigegeben wurde.

Im Verhältnis zu KI-Guardrails. Inhaltsfilter, Abwehr von Prompt-Injektionen und Ausgabefilter sind in der Regel probabilistisch und steuern, was das Modell erzeugt. Ob eine vorgeschlagene Finanzaktion autorisiert und ausführbar ist, ist eine eigene Feststellung, und genau diese trifft SAFR. SAFR greift nach der Inhaltsfilterung und vor der Ausführung.

Im Verhältnis zu Compliance-Plattformen. SAFR erzeugt den strukturierten Governance-Nachweis, auf den bestehende Compliance-Plattformen zugreifen können. Ihre Bewertungen bildet es nicht nach.

Im Verhältnis zu Abwicklungsinfrastrukturen. Zahlungsverfahren und Abwicklungssysteme bewegen Geld. SAFR steuert die Entscheidung, es zu bewegen. Durchsetzung auf Abwicklungsebene (Regeln der Kartennetzwerke, SWIFT-Standards, ACH-Regeln, das Machine Payments Protocol (MPP), Purpose Bound Money (PBM), Stablecoin-Kontrollen) greift, nachdem SAFR festgestellt hat, ob der Agent überhaupt handeln darf.

Im Verhältnis zu einem Produkt. SAFR ist eine Spezifikation. Die MAS bietet keinen verwalteten Dienst an; jedes Institut setzt das Muster in der eigenen Infrastruktur um oder nutzt Werkzeuge, die das tun.

Wer SAFR verfasst hat und das Umfeld¶

SAFR entstand in einem eigenen Arbeitsstrang, den die MAS im Rahmen ihres BuildFin.ai-Programms eingerichtet hat, um Umsetzungshilfen für die Risiken agentischer KI zu entwickeln. Version 1.0 wurde mit acht Branchenmitgliedern verfasst: Ant International, Circle, HSBC, J.P. Morgan Chase, Manulife, Mastercard, OCBC und Visa. Version 1.1 nennt elf Mitwirkende, ergänzt um DBS, Google und UOB, und fügt Fallstudien hinzu. Das Papier stützt die Spezifikation auf Fallstudien der Mitglieder, darunter das Agentic Treasury Protocol von Ant International, Agent Pay und Agentic Tokens von Mastercard, Visa Intelligent Commerce, die Agent Wallet von Circle, ERC-8004, Circle Payments Network und Compliance Engine, den Source of Wealth Assistant (SOWA) von OCBC mit der Bank of Singapore zusammen mit einem internen Agenten für Markt- und Kundenbriefings im Firmenkundengeschäft sowie die GenAI-Vertriebsunterstützung von Manulife. HSBC und J.P. Morgan Chase haben am Papier mitgewirkt, ohne namentlich genannte Fallstudien.

SAFR hat auch in der Governance-Literatur klar definierte Nachbarn. Project MindForge (die MAS mit einem Konsortium von Finanzinstituten aus Bankwesen, Versicherung und Kapitalmärkten) startete im November 2024 seine Phase 2 und veröffentlichte auf dem Singapore FinTech Festival im November 2025 ein Executive Handbook mit 17 Considerations in vier Abschnitten (Scope and Oversight, AI Risk Management, AI Lifecycle Management, Enablers) sowie ein Operationalisation Handbook zu minimalen Rechten für den Tool- und Datenzugriff von Agenten, Zertifizierung von Agenten, Aufteilung der Verantwortlichkeit zur Entwurfszeit, Kill Switches und Timeouts sowie Nachvollziehbarkeit durch durchsuchbare Protokollierung. Das Model AI Governance Framework for Agentic AI der IMDA (2026) beschreibt agentische Systeme anhand von vier Kernkomponenten (Modelle, Gedächtnis, Tools, Aktionen) und eines vierteiligen Governance-Modells (Abgrenzung des Anwendungsfalls, Zugriffsbeschränkung, menschliche Aufsicht, Verantwortlichkeit in der Prinzipal-Hierarchie). Das AI RMF des NIST (2023) steuert den Zyklus Map, Measure, Manage, Govern bei. SAFR ist die laufzeitspezifische Schicht dieses Stacks: Datenstrukturen, Bewertungslogik und Eskalationsverträge für den Moment des Handelns.

Das Papier schließt mit einer offenen Einladung: FinTechs und Finanzinstitute sind eingeladen, zu SAFR und der BuildFin.ai-Arbeitsgruppe beizutragen, indem sie Ergebnisse aus Pilotprojekten teilen, Lücken in der Spezifikation aufzeigen und fachliche Anforderungen einbringen, die noch nicht behandelt sind.

Nächste Schritte¶

Für ein Team, das seinen Stand gegenüber SAFR einschätzen will, ist eine strukturierte Lückenanalyse entlang der Dimensionen des Papiers der sinnvolle erste Schritt: Agenteninventar und Identität, Mandate, Kontrollen, Dispositionen, Envelope und Herkunftsnachweis, Eskalationsbetrieb, Audit und Nachweise sowie Bereitstellungsmuster. Die SAFR Readiness Checklist führt durch rund 35 Fragen im Stil eines Prüfers in diesen acht Abschnitten, bewertet die Reife je Abschnitt und bietet eine bearbeitbare Tabellenversion für Arbeitssitzungen.

Teams, die über die Bewertung hinaus bereits den Aufbau planen, sollten den Begleitbeitrag lesen, SAFR implementieren: Architektur, Muster und Make-or-Buy. Er behandelt die Referenzarchitektur, ausgearbeitete Kontrollbeispiele und eine Make-or-Buy-Analyse.

Wie KLA auf SAFR abbildet¶

KLA Control Plane setzt das SAFR-Muster um und ist heute verfügbar: Agent Registry für Agent Identity, Policy Builder für das Controls Repository, KLA Policy Engine für die Disposition Engine und Audit Trail für das Audit Log. Die vier Dispositionen sind eins zu eins abgebildet: Deny auf block, Escalate auf require_approval, Auto-Execute auf allow und Observe auf warn. Die vollständige Zuordnung Komponente für Komponente, einschließlich Betriebsanforderungen und aktueller Statusangaben, steht auf der SAFR-Implementierungsseite.