Safeguards for Agentic Finance at Runtime (SAFR) è un approccio di riferimento per un livello di governance runtime per l'intelligenza artificiale degli agenti nei servizi finanziari, pubblicato a luglio 2026 dal programma BuildFin.ai di MAS e scritto con Ant International, Circle, HSBC, J.P. Morgan Chase, Manulife, Mastercard, OCBC e Visa. Il white paper "definisce le strutture dei dati, la logica di valutazione e i contratti di escalation per l'implementazione dell'intelligenza artificiale con agenti". Lascia l'implementazione a ciascuna istituzione: SAFR "funge da riferimento del settore per le istituzioni da implementare all'interno della propria infrastruttura, utilizzando le proprie configurazioni di regole e accordi di governance".
Questa guida copre le decisioni ingegneristiche richieste dall'implementazione: l'architettura di riferimento, la scelta tra distribuzione nativa e gateway, cosa codificare nei controlli, calibrazione delle disposizioni, operazioni di escalation, livello di evidenza e analisi build-vs-buy. Poiché il quadro stesso (le quattro componenti, la busta di governance, i mandati e l'ecosistema attorno al SAFR) inizia con SAFR, spiegato. Per la mappatura KLA componente per componente, consultare la pagina Implementazione SAFR.
L'architettura di riferimento SAFR
SAFR "si colloca tra l'agente e i sistemi su cui agisce, valutando le azioni proposte prima dell'esecuzione, lavorando al contempo insieme ai binari di pagamento esistenti, ai protocolli di regolamento, ai motori di conformità e ai sistemi bancari principali". L'obiettivo progettuale, secondo le parole dell'articolo: "nessuna azione dell'agente raggiunge l'esecuzione senza essere stata dichiarata, autorizzata e valutata". Un'implementazione è una pipeline con un ordine fisso e un registro di controllo che ne registra ogni fase.
La pipeline funziona come segue. L'agente propone un'azione. Prima che qualsiasi cosa venga eseguita, la proposta viene confezionata in una Governance Envelope contenente tre classi di informazioni: l'azione stessa (tipo, ambito, parametri), la traccia dell'azione (i passaggi effettivamente eseguiti dall'agente per arrivare alla proposta, comprese le chiamate agli strumenti effettuate, i dati recuperati e i controlli eseguiti) e i metadati del contesto (identità dell'agente, mandato applicabile, conto corrente o stato del sistema e vincoli di politica operativa). La busta è convalidata per completezza e coerenza. L'identità dell'agente verifica quindi l'agente proponente rispetto al registro autorevole; una verifica fallita comporta un rifiuto immediato, registrato nel registro di controllo. Il repository dei controlli identifica quali controlli dell'istituzione applicare. Il motore delle disposizioni valuta l'azione rispetto a tali controlli e restituisce uno dei quattro risultati vincolanti: Nega, Escalate, Auto-Execute o Observe. I binari finanziari vengono eseguiti se e solo se il risultato lo consente e il registro di controllo registra la traccia completa della governance per ogni risultato, rifiuti inclusi.
L'integrità dell'involucro è un problema di progettazione di primo ordine. La traccia dell'azione e i dettagli dell'azione sono entrambi dichiarati dall'agente e una sofisticata iniezione avversaria può fabbricarli insieme. La prescrizione del documento: "La busta va quindi trattata come un documento da autenticare rispetto alla sua provenienza e non come una mera registrazione di quanto riferito dall'agente". In pratica questo spinge gli implementatori a catturare l'involucro in un punto che l'agente non può falsificare (all'interno del percorso di esecuzione o al confine della rete) ed è l'argomento più forte per scegliere deliberatamente il modello di distribuzione.
| Componente | Funzione | Nota di attuazione |
|---|---|---|
| Identità dell'agente | Vincola ciascuna azione proposta a un agente riconosciuto e registrato, verificato rispetto alla voce di registro di tale agente prima che proceda qualsiasi altra valutazione | In ambienti a circuito chiuso, una ricerca diretta nel registro dell'istituzione; sulle reti aperte il componente deve determinare quale tra diversi registri (interno, rete di pagamento, interistituzionale) è autorevole |
| Repositorio dei controlli | Il regolamento configurabile dell'istituto, tratto da politiche organizzative, requisiti normativi, regole di prodotto e mandati forniti dagli utenti | I controlli generici (controlli autorizzativi, limiti di esposizione) sono deterministici; I controlli specifici dell’intelligenza artificiale (qualità delle prove, integrità dell’involucro) possono comportare una valutazione probabilistica o semantica |
| Motore di disposizione | Valuta ogni azione nell'ambito in modo deterministico rispetto ai controlli recuperati | Produce "un risultato definito e vincolante per ogni azione proposta, calibrata sul rischio specifico che presenta" |
| Registro di controllo | Una registrazione immutabile, a prova di manomissione e di sola aggiunta di ogni decisione di governance | Registra tutti e quattro i risultati; vedere la sezione sul livello di prova di seguito |
Nativo o gateway: scelta di un modello di distribuzione
Il Libro bianco definisce due modelli di integrazione e la maggior parte delle istituzioni finirà per gestirli entrambi. SAFR, spiegato copre i meccanismi di ciascun modello, l'emissione dell'inviluppo nell'agente e l'intercettazione del gateway a livello dell'infrastruttura; la decisione di implementazione è quando scegliere quale.
Le indicazioni sulla sequenza provengono direttamente dal documento: "Per le istituzioni con molti agenti esistenti, il modello gateway funge da punto di partenza pratico stabilendo prima la copertura e la strumentazione nativa può seguire per le nuove build". Concretamente: le nuove funzionalità ottengono strumentazione nativa fin dal primo giorno e il patrimonio esistente ottiene un gateway di accesso. Esegui entrambi i modelli su un repository di controlli, un motore di disposizione e un registro di controllo, in modo che un'area mista produca un unico record di governance coerente.
| Modello | Quando sceglierlo |
|---|---|
| Integrazione nativa | Nuove distribuzioni di agenti, in cui la strumentazione dell'agente offre l'integrazione più stretta, la registrazione più granulare e la traccia di controllo più pulita |
| Integrazione del gateway | Sistemi legacy, agenti di terze parti e implementazioni esistenti, dove la copertura deve arrivare senza modifiche al codice dell'agente |
Cosa codificare nei controlli SAFR
Un controllo in SAFR codifica cinque cose: tipi di azioni consentite, logica decisionale, condizioni di escalation, un periodo di validità e l'autorità principale in base alla quale agisce l'agente. I controlli si basano su quattro fonti: politiche organizzative, requisiti normativi, regole di prodotto e mandati forniti dagli utenti.
Il mandato è l'ancora. "Un mandato è il meccanismo attraverso il quale un utente definisce i limiti dell'autorità delegata a un agente": esplicito e leggibile dalla macchina: cosa può fare l'agente, entro quali limiti, a quali condizioni. "Un agente non può estendere la portata di un mandato attraverso il proprio ragionamento o inferenza." Il lignaggio del progetto è la sicurezza basata sulle capacità, il modello alla base di OAuth 2.0; il documento cita l’Agent Payments Protocol (AP2), con i suoi mandati firmati crittograficamente, come un importante esempio del settore.
Il documento raggruppa i controlli in quattro categorie:
| Categoria | Cosa codificare | Cosa testare |
|---|---|---|
| Autorizzazione | Vincoli tra agente e entità principale, profondità di delega e una lista consentita di tipi di azione per classe di agente, tutti risolvibili al momento della valutazione | Un tipo di azione al di fuori della lista consentita viene negato anche da un agente registrato correttamente; viene negata una delega più profonda della profondità codificata |
| Limiti di esposizione | Soglie per azione e finestre aggregate ricavate dal framework di autorità delegata esistente, con le fasce di esecuzione automatica, escalation e nega dichiarate come importi espliciti | Un'azione che violerebbe il margine rimanente di una finestra aggregata aumenta anche quando il suo stesso importo rientra nella fascia per azione |
| Limiti di velocità | Un tasso di azione massimo per finestra temporale per ciascuna classe di agente, con un risultato definito per le azioni oltre il limite | Un burst oltre il limite, qualunque sia la sua causa (agente in fuga, errore nel feed di dati, iniezione avversaria), viene negato e contrassegnato per indagini |
| Qualità delle prove | Le prove richieste per ciascun tipo di azione e la soglia minima di confidenza dichiarata per l'esecuzione autonoma; la calibrazione della tesoreria di seguito richiede un record di fattura abbinato per pagamento | Un'azione la cui fiducia dichiarata scende al di sotto della soglia viene sottoposta alla revisione umana, qualunque sia il suo valore; test con una corrispondenza di prove deliberatamente debole |
Calibrazione dei controlli per un agente di pagamento della tesoreria
Ecco come appare calibrato per un agente di pagamento del Tesoro. I valori sono illustrativi; imposta il tuo dal quadro delle autorità delegate.
Per un agente di compliance-triage (arricchimento degli avvisi, proposte di disposizione del rischio, preparazione dell'archiviazione) i controlli che portano il carico sono soglie di qualità delle prove: la chiusura automatica di un avviso richiede che il contratto di prova sia soddisfatto pari o superiore alla soglia, le disposizioni ad alto rischio proposte passano a un revisore nominato e qualsiasi azione che sopprimerebbe un avviso aperto viene negata completamente. Percorriamo questo processo dall'inizio alla fine, attraverso tutti e quattro i componenti, in SAFR per AML e compliance triage.
| Controllare | Ambientazione illustrativa |
|---|---|
| Autorizzazione | La classe di agente treasury-payments può avviare pagamenti fornitore e interaziendali per le operazioni di tesoreria in qualità di mandante. Profondità della delega 1: l'agente può avere poteri delegati e non può subdelegare a nessun altro agente |
| Limite di esposizione per azione | Esecuzione automatica al di sotto di US$25,000. Incrementa da US$25,000 a US$250,000. Nega al di sopra del limite di US$250,000, dell'autorità delegata del desk |
| Finestra di esposizione aggregata | US$500,000 per 24 ore consecutive; un pagamento che eccederebbe il margine rimanente della finestra aumenta |
| Limite di tariffa | Numero massimo di operazioni di pagamento di 20 all'ora; le azioni oltre il limite vengono negate e contrassegnate per indagini |
| Qualità delle prove | Ogni pagamento deve fare riferimento ad un record di fattura abbinato; una corrispondenza al di sotto della soglia di confidenza passa alla revisione umana indipendentemente dall'importo |
| Periodo di validità | Mandato valido per il trimestre in corso; le azioni proposte al di fuori del periodo di validità vengono rifiutate |
Calibrazione delle quattro disposizioni
Ogni azione nell'ambito si risolve in uno dei quattro risultati del Disposition Engine:
Tutti e quattro i risultati alimentano il registro di controllo. L’assegnazione è guidata da cinque fattori di calibrazione nominati nel documento: reversibilità dell’azione, materialità finanziaria, gravità dell’impatto sul cliente, sensibilità normativa e novità o anomalia: deviazione dai modelli stabiliti all’interno del mandato. I profili a rischio più elevato spostano i risultati verso Nega o Incrementa. La calibrazione viene impostata in fase di progettazione attraverso i parametri di governance dei controlli, motivo per cui il piano pilota prevede un'intera settimana per l'ottimizzazione rispetto al traffico reale.
Observe merita un'attenzione progettuale deliberata: consente a un nuovo controllo di funzionare rispetto al traffico in tempo reale e di generare materiale di revisione strutturato mentre l'esecuzione continua, l'impostazione naturale per le soglie che intendi restringere dopo aver visto il comportamento reale.
| Disposizione | Cosa codificare | Cosa testare |
|---|---|---|
| Negare | Rigidi vincoli normativi e politici e soglie di rischio al di sopra delle quali un’azione viene respinta completamente; nella calibrazione della tesoreria, importi superiori a US$250,000, il tetto dell'autorità delegata del desk | Un'azione che viola un vincolo non raggiunge mai i binari e la relativa voce del registro di controllo indica la regola che è stata attivata e il motivo specifico |
| Aumentare | Le condizioni di escalation in ciascun controllo, indicando dove termina la banda autonoma al di sotto del limite Deny; Da US$25,000 a US$250,000 per l'agente di tesoreria | Il traffico simulato produce un volume di escalation che il team di revisione può cancellare e ogni escalation comporta una finestra di timeout predefinita per il blocco o per un revisore senior |
| Esecuzione automatica | La fascia autonoma che ciascun controllo lascia aperta: i tipi di azione, gli importi e le condizioni in cui l'esecuzione procede senza revisore nel percorso | Ciascuna azione eseguita automaticamente campionata mostra una traccia di governance completa: busta, regole applicate, base, tempi della fase |
| Osservare | Modelli e segnali configurati come meritevoli di attenzione al di sotto della soglia di escalation, ciascuno dei quali produce un'osservazione strutturata durante l'esecuzione dell'azione | Le osservazioni sono recuperabili e interrogabili al momento della revisione della soglia |
Operazioni di escalation: progettarle prima del go-live
Il documento descrive la tipica escalation odierna come una notifica, un avviso via e-mail o un flag sul dashboard, senza scadenza, senza formato decisionale standard, senza registrazione di audit: "l'apparenza di una supervisione umana senza la sua sostanza". Un'implementazione SAFR la sostituisce con un'operazione progettata, lungo tre dimensioni.
Volume. "Una funzione di escalation che genera più revisioni di quelle che l'istituzione può elaborare in modo significativo vanifica il suo stesso scopo." Soglie dimensionali rispetto alla capacità effettiva del revisore; se la simulazione produce più risultati di escalation di quelli che il team può eliminare, correggi i controlli prima del lancio.
Inversione di tendenza. Ogni escalation dovrebbe comportare una finestra di timeout. Se non arriva alcuna decisione al suo interno, l'impostazione predefinita è bloccare l'azione o passare a un revisore senior. Imposta la finestra temporale dalla disponibilità realistica del revisore, inclusa la copertura notturna e nel fine settimana.
Autorità. I revisori necessitano di una chiara autorità per approvare, modificare o rifiutare, e le loro decisioni "hanno lo stesso peso istituzionale della decisione originale dell'agente". Ciò implica nominare i singoli revisori, registrare le motivazioni di ogni decisione e definire i ruoli che si adattano alla gerarchia di approvazione esistente.
Autorizza nuovamente ogni passaggio
Nei processi a più fasi, il flusso di controllo si applica a ciascuna azione dell'agente in modo indipendente. "Un risultato di esecuzione automatica o di osservazione in un passaggio non comporta alcuna autorità in quello successivo", poiché l'agente si adatta ai risultati intermedi e alle condizioni mutevoli mentre funziona.
Questa singola frase ha grandi conseguenze implementative. Il percorso di valutazione deve essere sufficientemente veloce da poter essere eseguito su ogni azione, in modo che la latenza rientri nel budget di progettazione fin dall'inizio. I mandati devono essere risolvibili per azione. La memorizzazione nella cache dell'approvazione a livello di sessione è esclusa dalla progettazione. E un flusso di lavoro in dieci fasi produce dieci tracce di governance, ciascuna con il proprio involucro, disposizione e base: esattamente ciò che vorrà un ispettore che ricostruisce il percorso.
Il livello delle prove: il registro di controllo SAFR
Ogni voce del registro di controllo cattura sei cose: la busta di governance inviata, il mandato rispetto al quale è stata verificata l'azione, il risultato prodotto dal Disposition Engine, le regole specifiche applicate, la base per tale risultato e il tempo trascorso in ogni fase. Il registro è immutabile, antimanomissione e di sola aggiunta. Lo standard del documento: "Il registro è un documento autorevole, indipendente da qualsiasi parte interessata a come gli eventi vengono caratterizzati dopo il fatto."
Questo standard è superiore a quello fornito dalla normale registrazione delle applicazioni e tre proprietà necessitano di ingegneria fin dall'inizio: scritture di sola aggiunta, quindi i record si accumulano e non mutano mai; prove di manomissione, in pratica concatenamento crittografico, in modo che qualsiasi alterazione di un record passato sia rilevabile; e verificabilità indipendente, il che significa che un revisore può confermare l'integrità di un record esportato senza accedere alla piattaforma che lo ha prodotto. Perseverare le prove prima di restituire la disposizione. Se un'azione può essere eseguita mentre il suo record è ancora in corso, un arresto anomalo può lasciare le azioni eseguite senza traccia di governance.
Costruisci o acquista per il livello runtime SAFR
SAFR è un approccio di riferimento e la scelta del software è lasciata aperta. Divulgazione prima dell'analisi: KLA è un fornitore in questa categoria. KLA Control Plane implementa il modello SAFR, disponibile oggi. Leggi ciò che segue tenendo questo in mente.
Costruire internamente significa realizzare sei sottosistemi:
I sei sottosistemi insieme sono una costruzione su scala piattaforma e l'unità di pianificazione realistica è costituita dai quartieri del team. Il lavoro continua anche dopo il lancio: la calibrazione è un’attività operativa, perché le soglie cambiano con i volumi delle transazioni, i cambiamenti di prodotto e la capacità dei revisori.
Costruire ha senso quando si dispone di un team interno della piattaforma che possiederà il livello come prodotto, quando le ferrovie o l'infrastruttura di insediamento sono sufficientemente personalizzate da non poter ospitare un checkpoint standard o quando i sistemi adiacenti che già gestisci (diritti, gestione dei casi, strumenti politici) coprono parti reali della tabella sopra.
L’acquisto ha senso quando la priorità è la copertura governata e le prove esportabili entro un trimestre, quando non è disponibile un team della piattaforma per possedere sei sottosistemi o quando i revisori richiederanno record verificabili in modo indipendente prima che una tabella di marcia interna possa fornirli.
L'ibrido è spesso la risposta onesta: acquistare il checkpoint di runtime (registro, motore di disposizione, processo di escalation, archivio prove) e mantenere la creazione dei controlli internamente. La suddivisione corrisponde allo stesso SAFR: il quadro standardizza le strutture dei dati e i contratti, mentre le configurazioni delle regole e le disposizioni di governance rimangono dell’istituzione. In un ibrido, i team di rischio e conformità possiedono ciò che dicono i controlli e il fornitore gestisce il meccanismo che li applica e li dimostra.
Per la cronaca su KLA in particolare: KLA Control Plane mappa componente per componente (Registro agenti, Policy Builder, KLA Policy Engine, Audit Trail) con le quattro disposizioni espresse come consenti, avvisa, require_approval e blocca. Vengono forniti l'autorizzazione per azione, la valutazione a chiusura di errore e i pacchetti di prove sigillate con verifica offline. Sono in fase di sviluppo le finestre di esposizione aggregate, i limiti di velocità per finestra, le soglie di confidenza come primitiva di routing, i valori predefiniti di timeout di escalation per classe e il gateway autonomo. La mappa componente per componente, con indicatori di stato su ogni requisito, si trova sulla nostra pagina Implementazione SAFR.
| Sottosistema | Quello che serve |
|---|---|
| Registro degli agenti | Identità dell'agente registrato e con versione con proprietari nominati; delibera dell'anagrafe autorevole; verifica su ogni azione proposta |
| Repositorio dei controlli | Politiche con versione e leggibili dalla macchina; un flusso di lavoro di pubblicazione regolamentato con revisione e approvazione prima che una politica entri in vigore; copertura delle norme normative, di prodotto e derivate dal mandato |
| Motore di disposizione | Valutazione deterministica che produce i quattro risultati con codici motivo leggibili dalla macchina; semantica a chiusura di errore quando il servizio decisionale non è raggiungibile |
| Processo di escalation | Indirizzamento a revisori nominati con contesto di azione completo; approvare, modificare o rifiutare con motivazione registrata; gestione del timeout; visibilità delle code e dei turni di lavoro |
| Negozio di prove | Archiviazione di sola aggiunta e a prova di manomissione; utensili per l'esportazione; un percorso di verifica che una parte esterna può eseguire in modo indipendente |
| Strumentazione | Emissione di busta in ogni agente per l'integrazione nativa o un gateway di intercettazione per il patrimonio esistente, oltre al lavoro di latenza per mantenere valida la valutazione per azione |
Un pilota SAFR di quattro settimane
Una prima implementazione credibile richiede quattro settimane per un processo con ambito e il piano funziona indipendentemente dal fatto che il livello sottostante venga costruito, acquistato o ibrido.
Prima della prima settimana, segna la tua posizione. La SAFR Readiness Checklist è una valutazione interattiva delle lacune in otto sezioni, dall'identità dell'agente al modello di implementazione, con le prove che un valutatore richiederebbe allegate a ogni domanda.
| Settimana | Lavoro |
|---|---|
| 1 | Ambito del flusso di lavoro di un agente. Registrare l'agente, definirne il mandato e creare i controlli: ambito di autorizzazione, limiti di esposizione, limiti di tasso, soglie di qualità delle prove, condizioni di escalation |
| 2 | Esegui traffico governato nella simulazione. Valutare le azioni riprodotte o storiche rispetto ai controlli e calibrare le disposizioni finché il volume dell'escalation non corrisponde alla capacità del revisore |
| 3 | Vai in diretta con le escalation. Indirizza risultati reali Invia i risultati a revisori designati, misura i tempi di risposta rispetto alla finestra di timeout e ottimizza le soglie sul comportamento reale |
| 4 | Esportare le prove. Produrre i registri di audit per il periodo pilota, eseguire verifiche indipendenti sull'esportazione e tenere una lettura "prova/non-passa" con rischio e conformità |
Domande frequenti
Come possiamo aggiornare il patrimonio di un agente esistente?
Metti un gateway di fronte e fornisci la strumentazione nativa alle nuove build fin dal primo giorno, la sequenza consigliata dal white paper. Il lavoro di ingegneria si concentra in due luoghi: il punto di intercettazione, che dovrebbe trovarsi dove l'agente non può falsificare la busta, al confine della rete o all'interno del percorso di esecuzione; e il budget di latenza, perché la valutazione viene eseguita su ogni azione proposta. Esegui il gateway sullo stesso repository di controlli, motore di disposizione e registro di controllo delle build native in modo che l'ambiente misto produca un record di governance coerente.
Cosa richiede l'integrazione nativa dal nostro codice agente?
L'agente è dotato di strumenti per emettere una busta di governance prima di ogni azione proposta: il tipo di azione, l'ambito e i parametri; la traccia dell'azione; e metadati di contesto. Un validatore valuta la busta rispetto al repository dei controlli e restituisce un risultato prima che l'agente agisca. Il documento raccomanda l'integrazione nativa per le distribuzioni di nuovi agenti; offre l'integrazione più stretta, la registrazione più granulare e la traccia di controllo più pulita.
Che aspetto ha un pilota SAFR?
Quattro settimane su un flusso di lavoro con ambito: registrare l'agente e creare i suoi controlli; calibrare le disposizioni rispetto al traffico simulato o riprodotto; eseguire escalation in tempo reale con revisori nominati e ottimizzare le soglie; quindi esportare i record di audit, verificarli in modo indipendente e tenere una lettura "go/no-go" con rischio e conformità.
SAFR richiede una tecnologia specifica o un fornitore specifico?
No. SAFR definisce strutture di dati, logica di valutazione e contratti di escalation e "serve come riferimento di settore per le istituzioni da implementare all'interno della propria infrastruttura, utilizzando le proprie configurazioni di regole e accordi di governance". SAFR non è un servizio gestito. Le istituzioni possono soddisfarlo costruendo, acquistando o combinando le due cose.
Chi stabilisce le soglie in un’implementazione SAFR?
L'istituzione lo fa. Il SAFR "non costituisce una guida normativa o aspettative di vigilanza" e le configurazioni delle regole e gli accordi di governance restano di competenza dell'esecutore. In pratica: i limiti di esposizione provengono dal quadro delle autorità delegate esistenti, le soglie di escalation sono dimensionate rispetto all'effettiva capacità del revisore e la calibrazione delle disposizioni viene impostata in fase di progettazione utilizzando i cinque fattori nominati nel documento, dalla reversibilità dell'azione alla novità. Ogni istituzione rimane responsabile di determinare in che modo la sua implementazione si allinea alle aspettative di vigilanza applicabili e ai requisiti di governance interna.
Punti chiave
L'ordine di implementazione che funziona: scegli il tuo modello di distribuzione (nativo per le nuove build, gateway attraverso l'ambiente esistente), codifica i controlli dal tuo quadro di autorità delegata esistente, calibra le quattro disposizioni nella simulazione, progetta le operazioni di escalation rispetto alla reale capacità del revisore e crea un livello di prova che un esterno possa verificare. Quindi provalo su un processo in quattro settimane.
Inizia assegnando un punteggio al tuo stato attuale con la lista di controllo della preparazione al SAFR: una valutazione del gap interattiva e senza restrizioni; il foglio di lavoro modificabile è disponibile via email. Se vuoi avere un secondo sguardo sull'elenco delle lacune, prenota una revisione delle lacune SAFR di 30-minuti. E per la visualizzazione componente per componente dell'implementazione del framework SAFR sul piano di controllo KLA, incluso ciò che viene fornito e ciò che è in fase di sviluppo, vedere la pagina del pilastro.
Fonte: Safeguards for Agentic Finance at Runtime, white paper v1.0, MAS BuildFin.ai, luglio 2026. Passaggi citati © Monetary Authority of Singapore. Il SAFR è un riferimento del settore e non costituisce una guida normativa. KLA è indipendente e non è affiliata, approvata o certificata da MAS o BuildFin.ai.