SAFR-ausgerichtete Runtime Governance für einen Finanzagenten
Ein SAFR-ausgerichteter Runtime-Governance-Ansatz für einen Finanzagenten. Sehen Sie KLA-Runtime-Funktionen, Entwicklungsstand und einen Implementierungsplan für vier Wochen.
Was SAFR ist
SAFR (Safeguards for Agentic Finance at Runtime) ist ein Whitepaper, das im Juli 2026 im Rahmen des BuildFin.ai-Programms der MAS veröffentlicht wurde. Verfasst wurde es mit Ant International, Circle, HSBC, J.P. Morgan Chase, Manulife, Mastercard, OCBC und Visa. Es beschreibt einen Referenzansatz für eine Runtime-Governance-Schicht, die „zwischen dem Agenten und den Systemen, auf die er einwirkt, liegt und vorgeschlagene Aktionen vor der Ausführung bewertet“. Die zentrale Anforderung lautet: „Keine agentische Aktion erreicht die Ausführung, ohne deklariert, autorisiert und bewertet worden zu sein.“ SAFR ist eine Branchenreferenz, die Institute in ihrer eigenen Infrastruktur umsetzen können; das Whitepaper hält fest, dass es „keine regulatorische Leitlinie oder aufsichtliche Erwartung darstellt“.
Die KLA Control Plane stellt die Kontroll- und Evidenzmuster für eine SAFR-ausgerichtete Implementierung bereit. Der vierwöchige SAFR Production Sprint ist eine von KLA geleitete Zusammenarbeit rund um einen bestehenden Finanzagenten. Die Governance kundeneigener Agenten befindet sich in Entwicklung, während KLA die End-to-End-Qualifizierung abschließt. Diese Seite trennt KLA-Runtime-Funktionen von diesem Pfad. Eine vollständige Erläuterung des Frameworks finden Sie unter SAFR, erklärt.
Die SAFR-Komponentenübersicht
SAFR definiert vier Runtime-Komponenten, die über einen Governance Envelope zusammenwirken. Jede beantwortet vor der Ausführung eine Frage zu einer vorgeschlagenen Aktion. Die Tabelle ordnet jede Komponente der KLA-Runtime-Funktion zu, die sie umsetzt.
| SAFR-Komponente | Die beantwortete Frage | KLA-Funktion | Status |
|---|---|---|---|
| Agent Identity | Handelt es sich um einen bekannten, registrierten Agenten mit verifizierter Identität? | Agent Registry | KLA Runtime: ausgeliefert |
| Controls Repository | Was darf dieser Agent tun, in welchen Grenzen und unter welchen Bedingungen? | Policy Builder | KLA Runtime: ausgeliefert |
| Disposition Engine | Wird diese Aktion ausgeführt, markiert ausgeführt, zur Prüfung angehalten oder gestoppt? | KLA Policy Engine | KLA Runtime: ausgeliefert |
| Audit Log | Was wurde auf welcher Grundlage entschieden und kann ein Dritter dies später verifizieren? | Audit Trail | KLA Runtime: ausgeliefert |
Agent Identity → Agent Registry. SAFR verlangt, dass jede vorgeschlagene Aktion an einen bekannten, registrierten Agenten gebunden und vor jeder weiteren Bewertung gegen einen Registereintrag verifiziert wird; eine fehlgeschlagene Prüfung wird abgelehnt und aufgezeichnet. In KLA ist jeder Agent eine registrierte, versionierte Entität mit benanntem menschlichem Eigentümer und Freigabestatus. Die Runtime ist authentifiziert und mandantenisoliert, und jede vorgeschlagene Aktion trifft gebunden an eine verifizierte Agentenidentität ein.
Controls Repository → Policy Builder. Das SAFR-Kontrollregister ist das konfigurierbare Regelwerk des Instituts und basiert auf Organisationsrichtlinien, regulatorischen Anforderungen, Produktregeln und nutzerbereitgestellten Mandaten. In KLA sind Richtlinien versioniert und maschinenlesbar. Sie umfassen zulässige Tools und Aktionstypen, Entscheidungslogik und Eskalationsbedingungen. Die Veröffentlichung ist eine gesteuerte Freigabe: Richtlinien werden fail-closed gelintet und erfordern eine Vier-Augen-Freigabe im Decision Desk.
Disposition Engine → KLA Policy Engine. SAFR verlangt eine deterministische Bewertung mit „einem definierten, verbindlichen Ergebnis für jede vorgeschlagene Aktion, das auf das jeweilige Risiko abgestimmt ist“. In KLA wird jede vorgeschlagene Aktion vor der Ausführung gegen die veröffentlichte Richtlinienversion bewertet und zu einer von vier Entscheidungen aufgelöst. Maschinenlesbare Reason Codes sind für jede Entscheidung erforderlich; die Engine arbeitet fail-closed, wenn der Entscheidungsdienst nicht erreichbar ist.
Audit Log → Audit Trail. SAFR verlangt eine unveränderliche, manipulationssichere, append-only Aufzeichnung jeder Governance-Entscheidung. Sie erfasst den eingereichten Envelope, das geprüfte Mandat, das Ergebnis, die angewendeten Regeln, die Grundlage für das Ergebnis und die an jedem Schritt verstrichene Zeit. Der KLA Audit Trail ist append-only und manipulationssicher. Er zeichnet die Aktion und ihre Parameter, die Richtlinienversion, ausgelöste Regeln, die Entscheidung mit Reason Codes und jede menschliche Genehmigung auf. Der Export erfolgt als Sealed Evidence Bundles, die unabhängig von KLA offline verifiziert werden können.
Die vier SAFR-Entscheidungen
Die Disposition Engine von SAFR löst jede relevante Aktion in eines von vier Ergebnissen auf. Der Entscheidungswortschatz von KLA ordnet diese eins zu eins zu.
| SAFR-Entscheidung | KLA-Entscheidung | Verhalten |
|---|---|---|
| Deny | block | Die Aktion wird im Ausführungspfad gestoppt. Reason Codes sind verpflichtend. |
| Escalate | require_approval | Die Aktion pausiert. Eine Decision Request wird im Decision Desk an einen benannten, autorisierten Prüfer geleitet. |
| Auto-Execute | allow | Die Aktion wird ausgeführt. Die Entscheidung, ihr Kontext und ihre Richtliniengrundlage werden vollständig aufgezeichnet. |
| Observe | warn | Die Aktion wird markiert ausgeführt. Eine Stichprobenprüfungswarteschlange leitet ausgewählte Läufe zu einer geplanten menschlichen Stichprobenkontrolle. |
Alle vier Ergebnisse werden im Audit Trail aufgezeichnet. SAFR benennt fünf Kalibrierungsfaktoren für die Ergebniszuordnung: Reversibilität der Aktion, finanzielle Wesentlichkeit, Schwere der Kundenauswirkung, regulatorische Sensitivität sowie Neuartigkeit oder Anomalie gegenüber etablierten Mustern innerhalb des Mandats. Höhere Risikoprofile verschieben Ergebnisse in Richtung Deny oder Escalate. Die Kalibrierung wird bei der Gestaltung über die Governance-Parameter der Kontrollen festgelegt; in KLA bedeutet das die Schwellenwerte, die Sie im Policy Builder verfassen.
SAFR-Betriebsanforderungen A–H
Dies sind die Anforderungen, die eine SAFR-Implementierung im Betrieb erfüllen muss, und wie KLA Runtime jede davon erfüllt. Der SAFR Production Sprint für kundeneigene Agenten bleibt in Entwicklung, während KLA die End-to-End-Qualifizierung abschließt.
| # | Anforderung | Wie KLA sie erfüllt | Status |
|---|---|---|---|
| A | Governance Envelope, von Grund auf authentifiziert: Der Envelope ist „ein Dokument, das gegenüber seinem Ursprung authentifiziert werden muss“ | KLA Runtime stellt den Checkpoint-Datensatz im Ausführungspfad zusammen. Der kanonische Governance Envelope für kundeneigene Agenten befindet sich in Entwicklung. | KLA Runtime: ausgeliefert. Kundeneigener Agent: in Entwicklung |
| B | Autorisierung pro Aktion in mehrstufiger Arbeit: Eine vorherige Autorisierung „sollte nicht“ zwischen Schritten weitergelten | Jeder KLA-Runtime-Tool-Aufruf wird erneut autorisiert. allow in einem Schritt verleiht im nächsten keine Berechtigung. Mehrstufige Processes erlauben nur deklarierte Übergänge, verlangen die passende Akteursklasse und halten menschlich vorbehaltene Schritte architektonisch für Agenten geschlossen. | KLA Runtime: ausgeliefert |
| C | Autorisierung und Mandate: explizite, maschinenlesbare delegierte Befugnis | KLA-Runtime-Richtlinien binden Agenten über den Tool Catalog an zulässige Tools und Aktionstypen. Connector-Anmeldedaten liegen pro Verbindung im serverseitig eingegrenzten Secrets Vault. Die Qualifizierung des Mandatslebenszyklus für kundeneigene Agenten befindet sich in Entwicklung. | KLA Runtime: ausgeliefert. Kundeneigener Agent: in Entwicklung |
| D | Expositions- und Ratenlimits, Schwellenwerte pro Aktion und aggregiertem Wert sowie maximale Aktionsraten | Schwellenwerte pro Aktion sind heute Richtlinienentscheidungslogik. Execution Budgets begrenzen Schritte, Ausgaben und Laufzeit pro Ausführung und verfügen über einen erzwungenen Kill Switch sowie Incident-Hebel. Aggregierte Expositionsfenster und Ratenlimits pro Zeitfenster werden als Richtlinienprimitive entwickelt. | KLA-Runtime-Eingrenzung: ausgeliefert. Zeitfensterlimits: in Entwicklung |
| E | Evidenzqualität: Mindestevidenz und Konfidenz für autonome Ausführung | Die Richtlinie kann einen AI-Judge-Abgleich zwischen der Agentenausgabe und dem erwarteten Evidenzvertrag verlangen; eine Abweichung führt zu Eskalation oder Block. Content Rails für Injection-, Jailbreak- und Muster sensibler Daten laufen im selben Pfad. Konfidenzschwellenwerte als erstklassige Routing-Primitive werden entwickelt. | KLA-Runtime-Semantikprüfungen: ausgeliefert. Konfidenzschwellenwerte: in Entwicklung |
| F | Substanzielle menschliche Eskalation: Routing, Prüferbefugnis, Bearbeitungszeit | KLA-Runtime-Decision-Requests übermitteln den vollständigen Aktionskontext an rollenbasiert eingeschränkte, benannte Prüfer. Maker-Checker-Trennung wird serverseitig durchgesetzt. Das Eskalationsprofil des begrenzten SAFR Production Sprint befindet sich in Entwicklung. | KLA Runtime: ausgeliefert. Sprint-Profil: in Entwicklung |
| G | Der Audit-Datensatz: manipulationssicher, unabhängig verifizierbar | KLA Runtime gibt die Entscheidung erst zurück, wenn die Evidenz persistiert wurde, und arbeitet bei Schreibfehlern fail-closed. Das Ledger ist hash-verkettet. Die Qualifizierung des Evidenzexports für kundeneigene Agenten befindet sich in Entwicklung. | KLA Runtime: ausgeliefert. Kundeneigener Agent: in Entwicklung |
| H | Bereitstellungsmuster: native Instrumentierung und Gateway-Interception | Agenten auf KLA Runtime werden konstruktionsbedingt nativ gesteuert. KLA qualifiziert auf Dev einen Ingress für kundeneigene Agenten. | KLA Runtime: ausgeliefert. Kundeneigener Agent: in Entwicklung |
Architekturdetails, die Auswahl des Bereitstellungsmusters und eine SAFR-Anbieter-Build-vs-Buy-Analyse finden Sie unter SAFR implementieren.
Die vier SAFR-Evidenzartefakte
Eine verifizierte SAFR-Implementierung wird an den Datensätzen beurteilt, die sie erzeugt. Das Whitepaper formuliert es direkt: „Das Protokoll ist der maßgebliche Datensatz, unabhängig von jeder Partei, die ein Interesse daran hat, wie Ereignisse im Nachhinein charakterisiert werden.“ KLA Runtime erzeugt auf Anforderung vier Arten von Artefakten.
- Entscheidungsdatensatz mit Reason Codes. Jede bewertete Aktion löst sich zu
allow,warn,require_approvaloderblockauf, einschließlich maschinenlesbarer Reason Codes, der angewendeten Richtlinienversion und der konkret ausgelösten Regeln. - Lineage Record des Aktionstraces. Die Schritte, die der Agent beim Erreichen der vorgeschlagenen Aktion tatsächlich ausgeführt hat – Tool-Aufrufe, abgerufene Daten und durchgeführte Prüfungen – werden als manipulationssichere Lineage bewahrt und im Lineage Explorer rekonstruierbar gemacht.
- Decision-Desk-Genehmigungsdatensatz. Für jede eskalierte Aktion: der benannte Prüfer, seine rollenbasiert eingeschränkte Befugnis, das Ergebnis „genehmigen“ oder „ablehnen“ und die aufgezeichnete Begründung. Die Maker-Checker-Trennung wird serverseitig durchgesetzt.
- Sealed Evidence Bundle, offline verifizierbar. Ein Export mit signiertem Manifest, Einschlussbelegen pro Artefakt und einer externen Zeitstempelbindung. Auditoren, Prüfer oder Gegenparteien können ihn ohne Zugang zu KLA verifizieren.
Wenn ein SAFR-Softwareanbieter oder eine interne Implementierung nicht alle vier liefern kann, weist der Audit-Datensatz Lücken auf, die ein Prüfer finden wird.
Der vierwöchige SAFR Production Sprint
Der SAFR Production Sprint ist eine feste, vierwöchige, von KLA geleitete Implementierungszusammenarbeit für einen qualifizierten Finanzagenten. KLA übernimmt Integration und Konfiguration. Der Kunde bringt einen bestehenden Agenten, verantwortliche technische sowie Risiko- oder Compliance-Eigentümer, einen autorisierten Prüfer, repräsentative Fälle oder Testverkehr und eine angestrebte Produktionsentscheidung ein. KLA beginnt, nachdem die Gap-Analyse einen verifizierten Integrationsweg bestätigt hat.
| Woche | Arbeit | Ergebnis |
|---|---|---|
| 1 | Bestätigen des Day-0-Umfangs: ein Agent, eine folgenreiche Aktion, verantwortliche Eigentümer, Prüfer, System- und Datenpfad, Bereitstellungsweg, Erfolgsmaße und Produktionsentscheidungsdatum. | Ein dokumentierter Sprint-Umfang und Implementierungsplan |
| 2 | KLA installiert den gewählten Pfad, registriert Agent und Mandat, konfiguriert Kontrollen und kalibriert allow / warn / require_approval / block in der Simulation. | Ein konfigurierter Pfad und Kalibrierungsdatensatz für die Entscheidungen |
| 3 | Ausführen repräsentativen gesteuerten Verkehrs. Benannte Prüfer bearbeiten Decision Requests. KLA zeichnet Genehmigungen, Umgang mit ausbleibenden Entscheidungen, Fehler, Wiederholungen, Latenz und Evidenzvollständigkeit auf. | Gemessene Betriebsergebnisse und ein prüfbarer Eskalationsdatensatz |
| 4 | Export eines Sealed Evidence Bundle für den Sprint-Zeitraum. Ein unabhängiger Prüfer verifiziert es offline und dokumentiert die Produktionsempfehlung: Start, bedingter Start oder kein Start. | Ein Offline-Verifikationsergebnis und eine Produktionsentscheidung |
Ein ausgearbeitetes Beispiel für einen Compliance-Triage-Workload – die Anwendungsklasse, die das SAFR-Whitepaper dort nennt, wo Governance-Bedenken erhöht sind – finden Sie unter SAFR für AML.
Downloads und nächste Schritte
SAFR: Executive Briefing (PDF)
Neun Seiten für Entscheidungsträger: was das Framework von einem Institut verlangt, wer welchen Teil verantwortet, SAFR neben dem EU AI Act und FINMA 08/2024 sowie ein erstes Quartal, das mit verifizierbarer Evidenz endet.
Briefing anfordernSAFR-Implementierungskarte (PDF)
Zwei Seiten: die Komponentenübersicht, die Entscheidungsgrammatik und die Betriebsanforderungen A–H mit Status.
SAFR-Readiness-Checkliste
Bewerten Sie Ihren aktuellen Bestand in acht Bereichen: Agentenidentität, Mandate, Kontrollen, Entscheidungen, Envelope und Lineage, Eskalationsbetrieb, Audit und Evidenz sowie Bereitstellungsmuster. Auf der Seite ohne Zugangsschranke; die bearbeitbare Tabelle wird per E-Mail heruntergeladen.
Checkliste öffnen30-minütige SAFR-Gap-Analyse buchen
Bringen Sie einen bestehenden Finanzagenten, ein geplantes Produktionsfenster und die Personen mit, die dessen Kontrollen genehmigen können. Wir bestätigen den Integrationsweg und grenzen den nächsten Schritt ein.
30-minütige SAFR-Gap-Analyse buchenHäufige Fragen
- Ist SAFR verpflichtend?
- Nein. SAFR ist eine Branchenreferenz, die „keine regulatorische Leitlinie oder aufsichtliche Erwartung darstellt“, und jedes Institut entscheidet selbst über ihre Übernahme. Für Implementierende bedeutet das: Die Last der Ausrichtung liegt bei Ihnen. Jedes Institut bleibt dafür verantwortlich, zu bestimmen, wie seine Bereitstellung mit anwendbaren aufsichtlichen Erwartungen und internen Governance-Anforderungen übereinstimmt. Die Tabelle der Betriebsanforderungen auf dieser Seite ist eine Arbeitscheckliste für diese Bestimmung, und die SAFR-Readiness-Checkliste bewertet Ihren aktuellen Bestand nach denselben Grundlagen.
- Wer hat SAFR veröffentlicht?
- Das BuildFin.ai-Programm der MAS zusammen mit den Branchenmitgliedern Ant International, Circle, HSBC, J.P. Morgan Chase, Manulife, Mastercard, OCBC und Visa: Whitepaper Version 1.0, Juli 2026. Für Implementierende ist die praktische Form dieser Antwort die Quellenzeile für interne Governance-Dokumente, die sich auf eine SAFR-ausgerichtete Implementierung beziehen: „Safeguards for Agentic Finance at Runtime, Whitepaper v1.0, MAS BuildFin.ai, Juli 2026“ – dieselbe Attribution, die diese Seite im Footer trägt. Hintergrund zum Programm und Details zur Autorenschaft finden Sie unter SAFR, erklärt.
- Was sind die vier SAFR-Entscheidungen?
- In einer KLA-Implementierung entsprechen sie den vier Entscheidungen, zu denen eine veröffentlichte Richtlinie auflöst: Deny entspricht
block(die Aktion wird im Ausführungspfad gestoppt, Reason Codes sind verpflichtend), Escalate entsprichtrequire_approval(die Aktion pausiert, während eine Decision Request an einen benannten Prüfer im Decision Desk geleitet wird), Auto-Execute entsprichtallow(die Aktion wird ausgeführt, während Entscheidung und Richtliniengrundlage vollständig aufgezeichnet werden) und Observe entsprichtwarn(die Aktion wird markiert ausgeführt, mit ausgewählten Läufen für geplante menschliche Stichprobenprüfungen). Die SAFR Disposition Engine definiert die vier Ergebnisse und die fünf Kalibrierungsfaktoren; SAFR, erklärt erläutert die Begriffe. Die Implementierungsarbeit ist Kalibrierung: Die Schwellenwerte, die Sie im Policy Builder verfassen, entscheiden, wo jede Aktionsklasse landet. Woche zwei des obenstehenden Pilotplans ist der Feinabstimmung dieser Aufteilung gewidmet. - Ersetzt KLA unsere Compliance-Plattform?
- Nein. SAFR begrenzt die Runtime-Governance-Schicht auf die Erzeugung des strukturierten Governance-Datensatzes, auf den bestehende Compliance-Plattformen zugreifen können; es repliziert deren Bewertungen nicht. KLA folgt dieser Abgrenzung: Transaktionsüberwachung, Screening und Fallmanagement laufen dort weiter, wo sie heute laufen, und KLA liefert darunter die Entscheidung pro Aktion und den Evidenzdatensatz.
- Wie lange dauert ein SAFR-Pilot?
- Vier Wochen, nachdem eine Gap-Analyse einen verifizierten Integrationsweg und die Day-0-Eingaben bestätigt hat. Der Sprint umfasst Umfang, Installation und Kalibrierung, repräsentativen gesteuerten Verkehr, unabhängige Offline-Verifikation und eine dokumentierte Produktionsentscheidung.
- Können bestehende Agenten unter SAFR-Governance gestellt werden?
- KLA steuert heute Agenten auf KLA Runtime. Der Pfad für kundeneigene Agenten befindet sich in Entwicklung und wird auf Dev qualifiziert. KLA plant einen SAFR Production Sprint für externe Agenten, nachdem dieser Pfad seinen vollständigen Lauf für Entscheidungen, Genehmigung, Widerruf, Evidenz und Offline-Verifikation bestanden hat.
Quelle: Safeguards for Agentic Finance at Runtime, Whitepaper v1.0, MAS BuildFin.ai, Juli 2026. Zitierte Passagen © Monetary Authority of Singapore. SAFR ist eine Branchenreferenz und stellt keine regulatorische Leitlinie oder aufsichtliche Erwartung dar. KLA ist unabhängig von MAS oder BuildFin.ai und weder mit ihnen verbunden noch von ihnen empfohlen oder zertifiziert.