Un agente di pagamento della tesoreria può preparare o rilasciare un pagamento solo quando la richiesta è autentica, ogni parte e percorso rilevante ha il contesto attuale, l'autorità delegata è valida, le sanzioni e i controlli di pagamento restituiscono un risultato eseguibile e qualsiasi controllore richiesto approva la stessa istruzione vincolata prima della scadenza. Una potenziale corrispondenza di sanzioni, controparte vietata, conto non valido, campo obbligatorio incompleto, violazione assoluta dell'autorità o controllo obbligatorio non disponibile interrompe il rilascio.
Questa guida risponde a una domanda di implementazione limitata: come governare l'azione di un agente che prepara o rilascia un pagamento di tesoreria. La guida alla disciplina antiriciclaggio e agli agenti di pagamento copre il più ampio modello operativo pan-UE relativo alla criminalità finanziaria. Questa pagina mappa un'azione di svincolo del pagamento dall'acquisizione tramite la banca o la linea di pagamento e un pacchetto di prove sigillate. Utilizza allow, warn, require_approval e block come risultati della policy. Gli esempi sono sintetici e non prevedono alcuna soglia legale. L'ambito e l'aggiornamento della fonte sono stati esaminati il 28 luglio 2026. Confermare la legge, i programmi di sanzioni, le fonti degli elenchi, le regole di pagamento, i contratti e l'autorità interna che si applicano a ciascuna entità legale e percorso.
Mappa del processo end-to-end per il rilascio di un pagamento di tesoreria
L'unità governata è un'istruzione di pagamento esatta. La sequenza seguente nomina ogni attore, sistema, decisione, approvazione, fase di esecuzione, risultato a valle e artefatto di prova. Correlazione stabile e identificatori di esecuzione si uniscono al percorso completo.
- 1. Il richiedente e il sistema sorgente inviano la richiesta di pagamento. Le operazioni di Tesoreria ricevono l'istruzione attraverso un canale approvato. Il sistema di assunzione registra l'entità richiedente, l'identità del sistema di origine, l'autenticazione o la firma del messaggio, il digest dell'origine, l'ora della richiesta, il riferimento alla fattura o all'obbligo e l'elemento immutabile della richiesta di pagamento.
- 2. L'immissione convalida l'autenticità e la completezza. Il controllo dell'immissione conferma la fonte approvata, il modello, la firma o l'autenticazione del messaggio, i campi obbligatori e la chiave duplicata. Una fonte non valida o un campo obbligatorio mancante restituisce blocco e registra l'autenticità della fonte e gli artefatti di convalida.
- 3. Il processo assembla il contesto di pagamento. Collega pagatore, beneficiario, beneficiario, conti pagatore e beneficiario, banche e intermediari, giurisdizioni, valuta, importo, scopo, data di valuta, interruzione, percorso di pagamento e relativi riassunti pre-stato all'istruzione di pagamento.
- 4. L'infrastruttura di identità autentica gli attori. Il fornitore di identità della forza lavoro autentica il richiedente e l'eventuale revisore. Il provider di identità del carico di lavoro autentica il servizio e l'agente. Il servizio di autorità risolve lo scopo delegato, l'ambito dell'account, l'accesso allo strumento, i limiti di importo, l'ambiente, la scadenza e il limite dei dati assegnato.
- 5. L'agente di pagamento della tesoreria prepara la proposta di rilascio. L'agente legge i campi approvati, controlla la richiesta, chiama i servizi di screening e convalida approvati e propone un'azione
treasury.payment.release. Non può approvare se stesso, cambiare autorità, sopprimere prove o chiamare la linea di pagamento prima di un risultato rilasciabile. - 6. I sistemi di sanzioni e watchlist monitorano il percorso. Il servizio di screening controlla il pagatore, il beneficiario, il beneficiario, le banche, gli intermediari, le giurisdizioni e i fatti relativi alla proprietà o al controllo rispetto alle fonti dell'elenco applicabili dell'organizzazione e alla fonte dei record, alla versione, al tempo di recupero, al digest, agli input delle query, al risultato della corrispondenza e allo stato dell'aggiudicazione.
- 7. I sistemi di controllo dei pagamenti valutano l'istruzione. I controlli deterministici riguardano duplicati, stato della controparte e del conto, qualità dei dati, importo ed esposizione aggregata, anomalia, velocità, interruzione, valuta, data di valuta e restrizioni sui pagamenti. Ogni risultato diventa un input politico strutturato e un artefatto di prova.
- 8. Il motore delle policy di KLA valuta il contesto completo. La policy con versione restituisce allow, warn, require_approval o block, con un ID decisione, regole corrispondenti, codici motivo, policy digest, input digest e tempo di valutazione. Il risultato di corrispondenza più forte controlla l'esecuzione.
- 9. Decision Desk contiene richieste che richiedono approvazione. Una Richiesta di decisione presenta il pagamento esatto, il risultato dello screening, i controlli, l'incertezza, le ragioni politiche, l'identità del produttore, i ruoli di controllo richiesti, i limiti di autorità, la scadenza e la sintesi delle prove. I revisori indipendenti idonei approvano, rifiutano, riassegnano o intensificano in base alle regole del maker-checker e del multi-party.
- 10. Il gate di rilascio riconvalida l'istruzione associata. Il processo controlla il digest dell'azione, i campi di pagamento, le versioni delle policy e degli elenchi, le identità del revisore, il tempo di approvazione, la scadenza, l'autorità, il limite e lo stato aziendale corrente. Il contesto modificato o obsoleto crea una nuova valutazione e richiesta di decisione.
- 11. Il gateway della banca o il canale di pagamento esegue la chiamata consentita. Il servizio di rilascio invia l'istruzione associata con una chiave di idempotenza. La banca o la ferrovia resta l'esecutore del pagamento e restituisce lo stato di accettato, rifiutato, in sospeso, saldato, restituito o sconosciuto con il proprio riferimento.
- 12. Le operazioni di tesoreria riconciliano il risultato a valle. Il processo registra la ricevuta del pagamento, prima e dopo i digest, lo stato di liquidazione o restituzione, l'esito aziendale, lo stato del nuovo tentativo e qualsiasi riferimento a richiamo, compensazione, rollback o incidente.
- 13. Audit Trail e Lineage Explorer espongono il record ordinato. Gli eventi di richiesta, autenticità, autorità, screening, controlli di pagamento, politica, approvazione, strumento, percorso, esito, revoca e recupero rimangono uniti sotto un unico Lineage Record.
- 14. Evidence Room sigilla le prove. Un Pacchetto di prove sigillate contiene la popolazione di eventi ordinata, gli artefatti di origine e screening, le politiche e le decisioni umane, la ricevuta del pagamento, il trattamento della privacy, il manifest, gli hash degli artefatti, gli hash dei record, le firme e il risultato della verifica indipendente.
Associa il contesto di pagamento, l'autorità dell'agente, gli strumenti e i dati
Il controllo e l'approvazione del pagamento dipendono da dati accurati sulla parte e sul percorso. Preservare il pagatore, il beneficiario, il beneficiario finale, gli identificatori del conto, le persone giuridiche, le banche, gli intermediari, le giurisdizioni, la valuta, l'importo, lo scopo, le fatture, la data di valuta, il limite, il percorso di pagamento e la provenienza della fonte. Tokenizza o oscura gli identificatori esportati in base a una politica sulla privacy documentata preservando i join stabili.
Mantenere l'identità dell'agente, l'entità richiedente, l'utente delegato, l'identità del servizio e il proprietario responsabile separatamente attribuibili. Risolvere il mandato al limite del rilascio: conti del pagatore consentiti, classi di pagamento, strumenti, destinazioni, campi, scopo, valuta, limiti di importo e aggregati, ambiente, finestra temporale e limite dati. Un carico di lavoro autenticato può ancora non avere l'autorizzazione per questo pagamento.
L'agente di pagamento può richiamare solo strumenti approvati di acquisizione, screening, controparte, registro di tesoreria, policy, approvazione e gateway di pagamento. Ogni chiamata allo strumento richiede un ID e una versione canonici dello strumento, un pubblico o una destinazione, un digest degli argomenti, un tempo di richiesta e completamento, un digest dei risultati e un record di errori o effetti downstream.
- Autenticità della fonte: verifica l'identità del sistema di origine, l'autenticazione o la firma del messaggio, il modello, l'insieme di campi obbligatori, l'ora della richiesta e il digest della fonte prima della valutazione della policy.
- Contesto della parte e del conto: distinguere pagatore, beneficiario, beneficiario finale, conto debitore, conto creditore, banche, intermediari e fatti di proprietà o controllo.
- Giurisdizione e valuta: registra ogni giurisdizione che determina norme legali, sanzioni, tasse, controllo dei cambi, dati, interruzioni o politiche ferroviarie, con la valuta e il percorso applicabili.
- Autorità delegata: vincola il mandato dell'agente a uno scopo, classe di pagamento, popolazione del conto, set di strumenti, set di destinazioni, fascia di importo, esposizione aggregata, ambiente e scadenza.
- Limite dei dati: espone solo i campi approvati all'agente e al servizio di screening. Conserva i dati sensibili originali nel suo sistema autorevole ed esporta i riferimenti tokenizzati dove richiesto dalla politica.
Azioni consentite e vietate
Definire l'autorità dell'agente come operazioni esplicite. La stesura, il controllo, la proposta, l'approvazione e il rilascio comportano conseguenze diverse. L’approvazione di un revisore non può ampliare il diritto sottostante dell’agente o convertire un divieto assoluto in un’azione consentita.
| Azione | Autorità dell'agente | Controllo richiesto | Prova |
|---|---|---|---|
| Leggere una richiesta di pagamento approvata | Consentito all'interno del confine dei dati e dello scopo assegnati | Origine autenticata, richiesta assegnata, lista consentita dei campi, mandato attuale | Richiedente, agente, risorsa, scopo, campi, source digest, decisione dell'autorità |
| Convalida i campi parte, conto, importo, valuta e percorso | Consentito con strumenti di convalida di sola lettura | Controlli con versione e regole dei campi obbligatori con chiusura in caso di errore | Digest degli input, versione di convalida, risultato, campi mancanti o in conflitto |
| Esegui controlli su sanzioni, watchlist, duplicati, anomalie, velocità e interruzioni | Consentito tramite servizi approvati | Versioni attuali della sorgente e delle regole, input con ambito completo, risultato registrato | Servizio, versione dell'elenco o della regola, sintesi della query, risultato, ora, aggiudicazione |
| Preparare un'istruzione di pagamento | Consentito nell'ambito dello scopo e degli account delegati | Identità separata del preparatore e sintesi immutabile dell'azione proposta | Maker, contesto di pagamento, action digest, ora di creazione |
| Inviare un rilascio di pagamento vincolato | Consentito con riserva dopo un risultato di policy eseguibile | Autorità valida, controlli attuali, approvazioni richieste, capacità monouso, idempotenza | Politica, approvazioni, vincolo di azione, ricezione dello strumento, effetto a valle |
| Approvare la propria proposta o agire come controllore | Vietato | Confronto delle identità e applicazione del ruolo indipendente | Tentativo bloccato, identità del produttore, ruolo richiesto, codice motivo |
| Modifica il beneficiario, il beneficiario, il conto, l'importo, la valuta, lo scopo o il percorso dopo l'approvazione | Vietato ai sensi dell'approvazione esistente | Confronto digest e rivalutazione completa per qualsiasi modifica materiale | Modifica record, approvazione scaduta o annullata, nuovo risultato della policy |
| Cancellare una potenziale corrispondenza di sanzioni o alterare le prove di screening | Vietato a meno che la decisione non sia affidata a un ruolo arbitrale qualificato e distinto | Flusso di lavoro separato per l'aggiudicazione delle sanzioni e la fonte delle prove | Prova della corrispondenza, identità del giudice, autorità, logica, risultato |
| Crea autorità di revisore, disabilita controlli, sopprimi prove o riutilizza l'approvazione | Vietato | Operazioni amministrative negate, decisione monouso, percorso delle prove immutabili | Tentativo negato, regola politica, riferimento alla sicurezza o all'incidente |
| Rilascio tramite una banca, una compagnia ferroviaria, un conto, una giurisdizione o una credenziale non approvata | Vietato | Liste consentite di destinazione, pubblico, account, giurisdizione e credenziali | Chiamata bloccata, destinazione valutata, codici motivo, riferimento credenziale |
Tabella delle decisioni relative alle soglie e all'approvazione
Configura le bande dall'analisi legale dell'organizzazione, dalla valutazione del rischio di sanzioni, dal mandato di tesoreria, dal rischio di controparte, dalla politica di liquidità, dalle regole sui pagamenti e dai dati operativi osservati. Mantieni ogni controllo visibile in modo indipendente. Applica il risultato più efficace in questo ordine: blocca, richiedi_approvazione, avvisa, consenti.
La tabella fornisce una logica di controllo verificabile e non contiene alcuna soglia normativa universale. I campioni sintetici utilizzano EUR 125,000 e EUR 48,000 esclusivamente per individuare percorsi politici locali.
| Ingresso di controllo | permettere | avvisare | richiedere_approvazione | bloccare |
|---|---|---|---|---|
| Importo ed esposizione aggregata | All'interno della fascia di routine dell'agente e di tutti i limiti per pagamento, giornalieri, conto, entità e valuta | Vicino ad una banda operativa locale o inusuale rispetto al programma approvato | Al di sopra dell'autorità del produttore e all'interno dell'autorità del controllore nominato; la regola multiparty si applica quando configurata | Al di sopra dell'autorità assoluta, della liquidità, della controparte, del conto, della valuta o del limite legale |
| Sanzioni e watchlist | Tutte le proiezioni richieste sono state completate con le fonti attuali e un risultato chiaro | Segnale di qualità dei dati a basso rischio consentito con follow-up definito dalla politica locale | Una politica locale indirizza una potenziale corrispondenza risolvibile a un giudice qualificato delle sanzioni prima di qualsiasi decisione di rilascio | Divieto confermato, potenziale corrispondenza irrisolta in base alla politica di chiusura in caso di errore, fonte richiesta mancante, fonte non aggiornata o screening obbligatorio non disponibile |
| Controparte, beneficiario e conto | Parte e conto approvati con proprietà, banca, giurisdizione e contesto di scopo attuali | Parte nota con una modifica non sostanziale limitata selezionata per il follow-up | Nuovo beneficiario, conto modificato, giurisdizione a rischio elevato, cambio di proprietà o condizione di parte correlata all'interno della politica approvabile | Sono assenti soggetti vietati, conti chiusi o non validi, banche o ferrovie non approvate, giurisdizione vietata o fatti di proprietà richiesti per lo screening |
| Qualità dei dati e autenticità della fonte | Fonte approvata, autenticazione valida, campi completi, identificatori coerenti, record di supporto attuali | Completare la richiesta con un segnale di normalizzazione o freschezza non materiale | Prove contrastanti non obbligatorie che un controllore autorizzato può risolvere prima del rilascio | Fonte non valida, firma non riuscita, campo obbligatorio mancante, importo o valuta non corretti, identità del beneficiario in conflitto o istruzioni non verificabili |
| Anomalia | Il modello si adatta al programma di pagamento, alla controparte, all'importo, all'ora, alla valuta e al percorso approvati | Deviazione limitata all'interno dell'attuale autorità con un follow-up di garanzia definito | Modello nuovo, sequenza insolita, nuovo percorso, richiesta fuori orario o segnale di modello materiale entro limiti approvabili | L'indicatore di frode noto, la condizione del modello non controllata, la sequenza vietata o il servizio di anomalia richiesto dalla politica non sono disponibili |
| Duplicato e idempotenza | Nessuna chiave duplicata o precedente versione equivalente; una chiave di idempotenza non utilizzata | Possibile duplicato a monte con evidenza che il rilascio rimane identificato in modo univoco | La richiesta preventiva ambigua richiede la risoluzione delle operazioni di tesoreria prima del rilascio | Duplicato confermato, approvazione riutilizzata, chiave di idempotenza riutilizzata con argomenti incoerenti o precedente effetto positivo |
| Velocità e taglio | All'interno dei limiti di velocità per agente, conto, controparte, entità e treno e prima del limite | Vicino a una banda di velocità locale o di limite con tempo di assestamento sufficiente | Un flusso aggregato elevato o l’avvicinarsi del limite richiedono un controllore nominato e un contesto di liquidità attuale | Violazione della velocità assoluta, finestra chiusa, data di valuta scaduta o banca o ferrovia non disponibile in base alla politica di chiusura in caso di guasto |
Matrice delle responsabilità del maker-checker
Preparazione, revisione e rilascio rimangono compiti separati e verificabili. Il preparatore del pagamento crea o sponsorizza l'istruzione. Il controllore esamina in modo indipendente le prove rilegate. Il servizio di rilascio esegue solo l'istruzione approvata. Un giudice delle sanzioni è titolare della risoluzione della potenziale corrispondenza quando la politica locale consente tale percorso.
L'approvazione da parte di più parti richiede che ciascun ruolo nominato decida sotto l'autorità attuale. Registra sequenza, indipendenza, limiti, raccolta delle prove, decisione, motivo e tempo per ogni controllore. Una richiesta parzialmente approvata rimane trattenuta.
| Attività | Preparatore dei pagamenti | Controllore del tesoro | Giudice delle sanzioni | Servizio di rilascio | Proprietario responsabile |
|---|---|---|---|---|---|
| Autentica la fonte e assembla il pagamento | Responsabile | Esamina le eccezioni materiali | Consultato per lo screening dei campi | Nessuna azione | Responsabile della procedura |
| Eseguire screening e controlli deterministici | Può iniziare | Risultati delle revisioni | Responsabile dell'aggiudicazione della potenziale corrispondenza | Consuma i risultati finali | Responsabile per i proprietari assegnati |
| Preparare la proposta di rilascio | Responsabile come produttore | Nessuna modifica sul campo | Nessuna modifica sul campo | Nessuna azione | Responsabile del mandato |
| Approvare l'importo o l'eccezione di tesoreria | Non idoneo per la propria richiesta | Responsabile all'interno dell'attuale autorità | Consultato quando il contesto dello screening cambia | Nessuna azione | Responsabile della politica di approvazione |
| Risolvere una potenziale corrispondenza di sanzioni | Fornisce informazioni sulla fonte | Riceve il risultato | Responsabile sotto autorità separata | Nessuna azione se irrisolta | Responsabile del programma di sanzioni |
| Rilascia l'istruzione associata | Nessun rilascio diretto quando è richiesto il controllo | Decisione già registrata | Decisione già registrata | Responsabile di una chiamata idempotente | Responsabile del processo di pagamento |
| Riconciliare il risultato bancario o ferroviario | Responsabile del follow-up delle operazioni | Eccezione materiale recensioni | Consultato per sanzioni relative allo stato di trattenimento o rilascio | Ricevuta dei documenti | Responsabile per lo stato finale |
| Revoca, contiene e recupera | Supporta la riconciliazione | Supporta la decisione | Possiede azioni di risposta alle sanzioni | Interrompe le chiamate e i tentativi | Responsabile dell'incidente e del riavvio |
Imposta la scadenza, la riassegnazione e l'escalation dell'approvazione
La scadenza è un limite di autorizzazione. Impostalo in base all'aggiornamento dell'elenco delle sanzioni, alla volatilità del contesto di pagamento, al limite massimo, alla sensibilità al tasso di cambio e alla liquidità, alla disponibilità del revisore e alla finestra di conservazione sicura. La richiesta rimane trattenuta finché ogni controllore richiesto non decide.
La riassegnazione preserva l'assegnatario originale, il motivo, le prove, la scadenza e la cronologia. Il sostituto deve avere un'autorità uguale o maggiore per la classe di pagamento e l'importo corrente. La riassegnazione non ripristina mai automaticamente la scadenza.
Passare prima della scadenza al ruolo definito dalla policy. Una potenziale corrispondenza di sanzioni segue il percorso di escalation delle sanzioni-aggiudicazione. Un’interruzione bancaria o ferroviaria fa seguito all’escalation delle operazioni di pagamento e della resilienza. Una richiesta scaduta registra expired, esegue chiamate allo strumento di rilascio zero, aggiorna il contesto di screening e pagamento, valuta nuovamente la policy e crea una nuova richiesta di decisione.
| Condizione | Azione in coda | Stato di esecuzione | Prova |
|---|---|---|---|
| È richiesta una pedina singola | Assegnare una pedina idonea con autorità per la classe di pagamento e l'importo | Tenuto fino all'approvazione; interrotto al momento del rifiuto o della scadenza | Istantanea del ruolo, confronto del produttore, decisione, ragione, tempo, sintesi delle prove |
| È richiesta l'approvazione di più parti | Assegna ogni ruolo richiesto e preserva la sequenza configurata | Trattenuto finché tutte le approvazioni non saranno aggiornate e complete | Un record per pedina, ordine, autorità, indipendenza, scadenza |
| Assegnatario non disponibile | Riassegna a una pedina idonea e mantieni l'assegnazione originale | Detenuto alla scadenza originaria | Assegnatario precedente, nuovo assegnatario, attore, motivo, tempo |
| Scadenza prossima | Passare all'autorità configurata uguale o superiore | Tenuto | Attore dell'escalation, percorso, motivo, tempo, finestra rimanente |
| Scaduto o sostanzialmente modificato | Chiudi la richiesta di decisione e rivaluta il contesto attuale | fermato; è necessaria una nuova richiesta | Motivo di scadenza o modifica, zero chiamate allo strumento, input aggiornati, nuovo ID decisione |
Registrare l'esito della banca o del sistema di pagamento
L'KLA registra la decisione governata e la richiesta di rilascio strumentata. Il gateway bancario o la linea di pagamento connessa esegue il pagamento e rimane autorevole per lo stato di accettazione, rifiuto, regolamento, restituzione e richiamo.
Utilizzare una chiave di idempotenza per un'istruzione associata. Registrare il digest degli argomenti, la destinazione, l'ora della richiesta, il riferimento bancario o ferroviario, lo stato e il codice della risposta, prima e dopo i digest, lo stato di liquidazione o di restituzione e l'origine della riconciliazione. Una risposta API riuscita può comunque lasciare il risultato aziendale in sospeso o sconosciuto.
Riconciliare il pagamento con una fonte bancaria o ferroviaria ottenuta in modo indipendente. Mantieni aperti i risultati in sospeso e sconosciuti. Rifiuto del percorso, timeout, effetto parziale, restituzione o nuovo tentativo incoerente alle operazioni definite o al percorso dell'incidente. Cattura ogni successiva modifica dello stato con gli stessi identificatori di correlazione e esecuzione.
Mappare la sequenza degli eventi sullo schema degli eventi di controllo pubblico
Lo schema del registro di controllo dell'agente AI pubblico rappresenta un'azione governata dalla richiesta alla policy, all'approvazione, all'esecuzione, al risultato, alle prove, alla gestione della privacy e alla verifica dell'integrità. I dettagli di screening e convalida specifici del pagamento rimangono artefatti a cui fa riferimento il digest dalla busta comune.
| Fase di sequenza | Campo dello schema pubblico | Registro dei pagamenti del Tesoro |
|---|---|---|
| Inviluppo e correlazione | schema_version, audit_event.event_id, event_type, orari, sequence, correlation | Identificatori stabili di eventi, correlazione, esecuzione, traccia e intervallo per un'istruzione di pagamento |
| Organizzazione e conservazione | audit_event.scope | Riferimento dell'organizzazione pseudonima, ambiente, regione, classe di conservazione, conservazione legale |
| Richiesta, produttore, agente e proprietario | audit_event.actors | Richiedente, utente delegato, identità del servizio, agente, proprietario responsabile e provider di identità |
| Versioni di rilascio | audit_event.components | Agente, modello, modello di prompt e ID dell'agente di orchestrazione, versioni e digest di configurazione |
| Proposta di pagamento vincolato | audit_event.requested_action | Azione, scopo, risorsa di pagamento tokenizzata, confine dati, ambiente, importo, valuta, tempo richiesto |
| Screening e controlli sui pagamenti | audit_event.policy più evidence.artifacts[] | Le decisioni politiche e le motivazioni fanno riferimento ad elementi per l'autenticità della fonte, elenchi di sanzioni, screening, duplicati, anomalie, velocità, interruzione, controparte e qualità dei dati |
| Decisione del maker-checker | audit_event.approval | Richiesta di decisione, stato, tempi, scadenza, ruolo richiesto, raccolta di prove, revisore, decisione, motivo, logica, riassegnazione o eccezione |
| Rilascio della chiamata ed effetto ferroviario | audit_event.tool_calls[] | Strumento e versione, azione, destinazione bancaria o ferroviaria, digest degli argomenti, chiave di idempotenza, risultato, effetto downstream e riferimenti |
| Esito aziendale e di ripresa | audit_event.execution | Stato e tempi di esecuzione, risultati aziendali raggiunti o non risolti, rollback, richiamo, restituzione, risarcimento o riferimento all'incidente |
| Record e artefatti ordinati | audit_event.lineage e audit_event.evidence | ID record di derivazione, ID eventi ordinati, riferimento manifest, ID artefatto, tipi e digest di contenuto |
| Gestione della privacy | audit_event.privacy | Stato di classificazione, tokenizzazione o redazione, puntatori JSON, metodi e policy di accesso |
| Verifica dell'integrità | integrity | Canonicalizzazione RFC 8785, hash del record SHA-256, hash del predecessore quando utilizzato, firma Ed25519, verificatore, ora, stato e codici di errore |
Analisi del campione disinfettata riuscita
Questo esempio sintetico propone un rilascio di pagamenti di tesoreria EUR 125,000. La figura è illustrativa. Le sanzioni e lo screening delle watchlist tornano chiari. L'importo supera una fascia di maker-checker locale, quindi la polizza restituisce richiede_approvazione. Un funzionario senior del Tesoro sintetico approva le stesse istruzioni prima della scadenza. Lo strumento di rilascio utilizza una chiave di idempotenza, il gateway bancario sintetico restituisce una ricevuta di accettazione e i report di verifica dell'integrità sono validi. Scarica l'esempio JSON approvato.
{
"schema_version": "1.0.0",
"audit_event": {
"event_id": "evt_synthetic_treasury_approved_20260728",
"event_type": "agent.action.completed",
"occurred_at": "2026-07-28T09:15:08.481Z",
"recorded_at": "2026-07-28T09:15:08.612Z",
"sequence": 18,
"correlation": {
"correlation_id": "corr_synthetic_treasury_approved_20260728",
"execution_id": "run_synthetic_treasury_approved_20260728",
"trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
"span_id": "00f067aa0ba902b7"
},
"scope": {
"organization_ref": "orgref_synthetic_eu_treasury_01",
"environment": "production-eu",
"region": "eu-west",
"retention_class": "regulated-payment-7y",
"legal_hold": false
},
"actors": {
"requester": {
"id": "usr_synthetic_treasury_maker_017",
"type": "user",
"display_name": "Synthetic treasury payment preparer",
"identity_provider": "workforce-iam"
},
"delegated_user": {
"id": "usr_synthetic_treasury_maker_017",
"type": "user",
"identity_provider": "workforce-iam"
},
"service_identity": {
"id": "svc_synthetic_treasury_agent_prod",
"type": "service",
"identity_provider": "workload-identity"
},
"agent": {
"id": "agent_synthetic_treasury_release",
"type": "agent",
"display_name": "Synthetic treasury payment-release agent"
},
"accountable_owner": {
"id": "role_synthetic_head_treasury_operations",
"type": "organization",
"display_name": "Synthetic head of treasury operations"
}
},
"components": {
"agent": {
"id": "treasury-payment-release-agent",
"version": "release-2026.07.28.1",
"configuration_digest": "sha256:65b95530f15bb617be582f2cd23a9bc4e9f4144623a43975266a6f7ce1510a2f"
},
"model": {
"id": "treasury-payment-context-model",
"version": "2026-07-10",
"configuration_digest": "sha256:8721063842a566d2d48c8ffc912b370e13846d0c9a2665f72a62e153c791d14d"
},
"prompt_template": {
"id": "treasury-release-system-prompt",
"version": "5.3.0",
"configuration_digest": "sha256:dc675cfacd5001e356062d0c82bb2cf4ddfa8417929e0d7cfdc1a7bba9f6c300"
},
"orchestrator": {
"id": "treasury-payment-release-process",
"version": "14",
"configuration_digest": "sha256:4499ee0f6418cfde2095492fd15833425502d6c387f8c1c11e81c37a4a4b4f4c"
}
},
"requested_action": {
"action": "treasury.payment.release",
"purpose": "release-approved-treasury-payment",
"resource": {
"type": "payment_instruction",
"id": "payment_synthetic_20260728_0042"
},
"data_boundary_ref": "boundary_eu_treasury_restricted",
"environment": "production-eu",
"amount": {
"value": "125000.00",
"currency": "EUR"
},
"requested_at": "2026-07-28T09:14:29.122Z"
},
"policy": {
"decision_id": "dec_synthetic_treasury_approved_20260728",
"policy_id": "treasury-payment-release-policy",
"policy_version": "7.2.0",
"policy_digest": "sha256:dfb0b86f9e69ed9613e6c347632ff1bf0813eb570439e01a18cd7e56c686091b",
"inputs_digest": "sha256:f3b9e01da2e24bea435b44b4c312a6d05de54075bf992bd6bb0ed79a22c07bc0",
"decision": "require_approval",
"evaluated_at": "2026-07-28T09:14:29.188Z",
"matched_rule_ids": [
"sanctions-screening-clear",
"approved-beneficiary-and-account",
"maker-checker-above-local-band"
],
"reason_codes": [
"screening_clear",
"amount_requires_senior_treasury_checker"
]
},
"approval": {
"request_id": "dr_synthetic_treasury_approved_20260728",
"status": "decided",
"requested_at": "2026-07-28T09:14:29.214Z",
"expires_at": "2026-07-28T09:44:29.214Z",
"required_role": "senior_treasury_officer",
"presented_evidence_digest": "sha256:fe7d8a9a4b28878e66443038d1896ea748a00b748cbe7fdc3341479b891816fe",
"reviewer": {
"id": "usr_synthetic_senior_treasury_031",
"type": "user",
"display_name": "Synthetic senior treasury officer",
"identity_provider": "workforce-iam"
},
"decision": "approved",
"reason_code": "screening_and_payment_context_verified",
"rationale_reference": "decision-note-synthetic-tokenized-031",
"decided_at": "2026-07-28T09:15:07.902Z"
},
"tool_calls": [
{
"call_id": "call_synthetic_payment_rail_20260728",
"tool_id": "bank-gateway.payment-release",
"tool_version": "2026-07-20",
"action": "release_payment",
"destination": "synthetic-bank-rail-eu",
"requested_at": "2026-07-28T09:15:07.944Z",
"arguments_digest": "sha256:5e7c5f9b53ac522ecdc5f476176053e61d72a78b9475386f046c4a6bf04f2a48",
"idempotency_key": "run_synthetic_treasury_approved_20260728:release-payment",
"status": "succeeded",
"completed_at": "2026-07-28T09:15:08.433Z",
"result_digest": "sha256:4a2f28f803051c238f66e218eec02e65691556c4b4128d482d1f8dd90a081e77",
"downstream_effects": [
{
"system": "synthetic-bank-rail-eu",
"effect_type": "payment_instruction_accepted",
"effect_reference": "rail-receipt-synthetic-20260728-0042",
"before_state_digest": "sha256:a5f3c6a11b62647f2cc95e50befb5b8e7e4ad9fe4f374691ddd6610f16297109",
"after_state_digest": "sha256:0932e223fcb9c36ea2cee608b9c2135f5dba43cd73ea1d6d593b7e6091ef5135"
}
]
}
],
"execution": {
"status": "succeeded",
"started_at": "2026-07-28T09:15:07.920Z",
"completed_at": "2026-07-28T09:15:08.481Z",
"business_outcome": {
"status": "achieved",
"summary": "The synthetic bank gateway accepted the approved payment instruction and returned a rail receipt.",
"reference": "outcome_synthetic_payment_accepted_0042"
},
"rollback": {
"status": "not_required",
"reference": "rollback-policy-synthetic-treasury-release"
}
},
"lineage": {
"lineage_record_id": "lin_synthetic_treasury_approved_20260728",
"ordered_event_ids": [
"evt_synthetic_payment_intake_0042",
"evt_synthetic_screening_clear_0042",
"evt_synthetic_policy_approval_required_0042",
"evt_synthetic_checker_approved_0042",
"evt_synthetic_rail_accepted_0042",
"evt_synthetic_treasury_approved_20260728"
]
},
"evidence": {
"manifest_ref": "bundle_manifest_synthetic_treasury_approved_20260728",
"artifacts": [
{
"artifact_id": "artifact_synthetic_source_authenticity_0042",
"artifact_type": "payment-source-authenticity",
"content_digest": "sha256:6c793181b83d28123a27328a2a5d65ce8dbcbb56f923649d7b43a22a9303c76d"
},
{
"artifact_id": "artifact_synthetic_sanctions_clear_0042",
"artifact_type": "sanctions-screening-result",
"content_digest": "sha256:a17aaf56c5bd7c85dc8e3d49c74ea01c79749668be8e93b3b2bf57c3908f27f3"
},
{
"artifact_id": "artifact_synthetic_approval_0042",
"artifact_type": "approval-decision",
"content_digest": "sha256:0859f92f8b7ec439bc004baad8b4fc93851c14bf0de8a3511619882e2d1db43b"
},
{
"artifact_id": "artifact_synthetic_rail_receipt_0042",
"artifact_type": "payment-rail-receipt",
"content_digest": "sha256:f27fede2220bcd326aee3bcff314c4dccfa3e5d5cb8b9287d06d654345ae29cd"
}
]
},
"privacy": {
"classification": "restricted",
"redaction_status": "tokenized",
"redactions": [
{
"json_pointer": "/actors/requester/id",
"method": "tokenized"
},
{
"json_pointer": "/requested_action/resource/id",
"method": "tokenized"
}
],
"access_policy_ref": "evidence-access-synthetic-regulated-treasury"
}
},
"integrity": {
"canonicalization": "RFC8785-JCS",
"hash_algorithm": "SHA-256",
"record_hash": "sha256:6f1d65f09f7bd8eea22bc06c76d58b9a983ab9066232f025245c5c5bee5f937d",
"signature": {
"algorithm": "Ed25519",
"key_id": "synthetic-treasury-sample-key-2026-01",
"public_key_spki": "MCowBQYDK2VwAyEAUENkPpZZtnjq0OZHXSf2GV7zpmIvHrd6L8LrONvUn8o=",
"value": "Ue+Naudajb+Tmv/Qm+k8c2p+SfVC/RKb9Xp6uWd9jyeZTVJnFrFxLXYJXAp2UZ4SpwAsNnAbYSCnuh90ghN8Cw=="
},
"verification": {
"status": "valid",
"verified_at": "2026-07-28T09:15:09.041Z",
"verifier": {
"id": "vendor-neutral-reference-verifier",
"version": "1.0.0"
},
"failure_codes": []
}
}
}Corsa negativa delle sanzioni bloccate
Questo esempio sintetico registra una potenziale corrispondenza di sanzioni e watchlist con il contesto del beneficiario. La policy restituisce blocco con i codici motivo sanctions_watchlist_hit e beneficiary_requires_sanctions_adjudication. L'evento comporta zero chiamate allo strumento, l'esecuzione rimane not_started e il pagamento rimane non rilasciato. Scarica l'esempio JSON del blocco delle sanzioni.
{
"schema_version": "1.0.0",
"audit_event": {
"event_id": "evt_synthetic_treasury_sanctions_block_20260728",
"event_type": "agent.action.denied",
"occurred_at": "2026-07-28T11:03:18.092Z",
"recorded_at": "2026-07-28T11:03:18.144Z",
"sequence": 5,
"correlation": {
"correlation_id": "corr_synthetic_treasury_sanctions_block_20260728",
"execution_id": "run_synthetic_treasury_sanctions_block_20260728",
"trace_id": "0af7651916cd43dd8448eb211c80319c",
"span_id": "b7ad6b7169203331"
},
"scope": {
"organization_ref": "orgref_synthetic_eu_treasury_01",
"environment": "production-eu",
"region": "eu-west",
"retention_class": "regulated-payment-denial-7y",
"legal_hold": false
},
"actors": {
"requester": {
"id": "usr_synthetic_treasury_maker_024",
"type": "user",
"display_name": "Synthetic treasury payment preparer",
"identity_provider": "workforce-iam"
},
"service_identity": {
"id": "svc_synthetic_treasury_agent_prod",
"type": "service",
"identity_provider": "workload-identity"
},
"agent": {
"id": "agent_synthetic_treasury_release",
"type": "agent",
"display_name": "Synthetic treasury payment-release agent"
},
"accountable_owner": {
"id": "role_synthetic_head_treasury_operations",
"type": "organization",
"display_name": "Synthetic head of treasury operations"
}
},
"components": {
"agent": {
"id": "treasury-payment-release-agent",
"version": "release-2026.07.28.1",
"configuration_digest": "sha256:65b95530f15bb617be582f2cd23a9bc4e9f4144623a43975266a6f7ce1510a2f"
},
"model": {
"id": "treasury-payment-context-model",
"version": "2026-07-10",
"configuration_digest": "sha256:8721063842a566d2d48c8ffc912b370e13846d0c9a2665f72a62e153c791d14d"
},
"prompt_template": {
"id": "treasury-release-system-prompt",
"version": "5.3.0",
"configuration_digest": "sha256:dc675cfacd5001e356062d0c82bb2cf4ddfa8417929e0d7cfdc1a7bba9f6c300"
},
"orchestrator": {
"id": "treasury-payment-release-process",
"version": "14",
"configuration_digest": "sha256:4499ee0f6418cfde2095492fd15833425502d6c387f8c1c11e81c37a4a4b4f4c"
}
},
"requested_action": {
"action": "treasury.payment.release",
"purpose": "release-approved-treasury-payment",
"resource": {
"type": "payment_instruction",
"id": "payment_synthetic_20260728_0099"
},
"data_boundary_ref": "boundary_eu_treasury_restricted",
"environment": "production-eu",
"amount": {
"value": "48000.00",
"currency": "EUR"
},
"requested_at": "2026-07-28T11:03:18.021Z"
},
"policy": {
"decision_id": "dec_synthetic_treasury_sanctions_block_20260728",
"policy_id": "treasury-payment-release-policy",
"policy_version": "7.2.0",
"policy_digest": "sha256:dfb0b86f9e69ed9613e6c347632ff1bf0813eb570439e01a18cd7e56c686091b",
"inputs_digest": "sha256:36cdde251024f5c6ba4a69127ee16b4fddbd3c2101995d9d8d0a135c54a9f16e",
"decision": "block",
"evaluated_at": "2026-07-28T11:03:18.081Z",
"matched_rule_ids": [
"sanctions-watchlist-potential-match",
"payment-release-fail-closed"
],
"reason_codes": [
"sanctions_watchlist_hit",
"beneficiary_requires_sanctions_adjudication"
]
},
"tool_calls": [],
"execution": {
"status": "not_started",
"business_outcome": {
"status": "not_achieved",
"summary": "The synthetic payment instruction remained unreleased because sanctions screening produced a potential match.",
"reference": "outcome_synthetic_sanctions_block_0099"
}
},
"lineage": {
"lineage_record_id": "lin_synthetic_treasury_sanctions_block_20260728",
"ordered_event_ids": [
"evt_synthetic_payment_intake_0099",
"evt_synthetic_sanctions_match_0099",
"evt_synthetic_policy_block_0099",
"evt_synthetic_treasury_sanctions_block_20260728"
]
},
"evidence": {
"manifest_ref": "bundle_manifest_synthetic_treasury_sanctions_block_20260728",
"artifacts": [
{
"artifact_id": "artifact_synthetic_source_authenticity_0099",
"artifact_type": "payment-source-authenticity",
"content_digest": "sha256:51621194f1179592adf5b28ed1273d74ea8a3e215563cad3134bc67c5b2e8484"
},
{
"artifact_id": "artifact_synthetic_sanctions_match_0099",
"artifact_type": "sanctions-screening-result",
"content_digest": "sha256:40bb1e4f2cfdad1809979b5768bab770c18cfef2c96fe74bd0458952a30a6858"
},
{
"artifact_id": "artifact_synthetic_policy_block_0099",
"artifact_type": "policy-decision",
"content_digest": "sha256:3dd5603753882085593a880d61c92e65e0ec758253c810b23e08dc7ba4cf2a32"
}
]
},
"privacy": {
"classification": "restricted",
"redaction_status": "tokenized",
"redactions": [
{
"json_pointer": "/actors/requester/id",
"method": "tokenized"
},
{
"json_pointer": "/requested_action/resource/id",
"method": "tokenized"
}
],
"access_policy_ref": "evidence-access-synthetic-regulated-treasury"
}
},
"integrity": {
"canonicalization": "RFC8785-JCS",
"hash_algorithm": "SHA-256",
"record_hash": "sha256:8d2eba7b69efc2cc5c78ffea6aa25abd93ffb4ceed8ba51801227bd4d27158c4",
"signature": {
"algorithm": "Ed25519",
"key_id": "synthetic-treasury-sample-key-2026-01",
"public_key_spki": "MCowBQYDK2VwAyEAUENkPpZZtnjq0OZHXSf2GV7zpmIvHrd6L8LrONvUn8o=",
"value": "9ARCGoapZmSSOlMss+P7S9UCkYYg1P9almO1s66dfqoLSrd+nln/J8hFoxFCf3DKW9A5Fg4TrFCRkKeljSDdBw=="
},
"verification": {
"status": "valid",
"verified_at": "2026-07-28T11:03:18.311Z",
"verifier": {
"id": "vendor-neutral-reference-verifier",
"version": "1.0.0"
},
"failure_codes": []
}
}
}Modalità di fallimento e ripristino
Testa il percorso completo in caso di richieste non valide, elenchi obsoleti, modifiche di identità, errori di coda, nuovi tentativi, interruzioni del servizio ferroviario, effetti parziali e ripristino degli incidenti. Mantenere il processo in uno stato sicuro definito fino al completamento della riconciliazione a valle e delle prove richieste.
| Modalità di fallimento | Controllo immediato | Percorso di recupero | Prova |
|---|---|---|---|
| Richiesta di pagamento non autentica, non valida o incompleta | Restituisci blocca prima dello screening o del rilascio | Correggere l'istruzione di origine e inviare una nuova richiesta | Identità di origine, campo o firma non riuscita, decisione, nuovo riferimento alla richiesta |
| Elenco delle sanzioni, servizio di screening o dati richiesti non disponibili | Applica il blocco di chiusura in caso di errore configurato | Ripristinare o sostituire la fonte approvata, ricontrollare ogni parte e percorso, rivalutare la politica | Stato della dipendenza, versione di origine, interruzione, screening aggiornato, nuova decisione |
| Corrispondenza di sanzioni potenziale o confermata | Mantenere il pagamento non sbloccato e revocare qualsiasi capacità di rilascio in sospeso | Indirizzare le potenziali corrispondenze al processo di aggiudicazione qualificato; seguire la procedura di blocco, rifiuto, segnalazione o rilascio applicabile | Abbina input, elenco e programma, giudice, base giuridica, disposizione, regolatore o riferimento all'incidente, ove applicabile |
| Richiesta duplicata o chiave di idempotenza riutilizzata | Blocca il riutilizzo incoerente e interroga la banca o la ferrovia per il risultato precedente | Riconciliare l'istruzione originale; creare una nuova istruzione unica solo secondo la procedura approvata | Chiavi duplicate, sintesi di argomenti, ricevuta preventiva, decisione di riconciliazione |
| Revisore non disponibile o conflitto trovato | Conserva la richiesta | Riassegna o passa a una pedina idonea entro la scadenza originale | Risultato del conflitto, assegnazioni, motivo, istantanee dell'autorità, tempi |
| L'approvazione scade o il contesto di pagamento cambia | Invalidare l'autorità di rilascio ed eseguire zero chiamate allo strumento | Aggiorna fonte, screening, account, importo, interruzione, policy e contesto di identità; emettere una nuova richiesta di decisione | Scadenza o modifica, approvazione chiusa, input aggiornati, nuova decisione |
| La banca o la ferrovia rifiutano l'istruzione | Registra l'effetto downstream rifiutato e interrompi i tentativi automatici che modificano gli argomenti | Correggere la causa attraverso una nuova istruzione governata o chiudere il pagamento | Riferimento ferroviario, codice, ricevuta, decisione del proprietario, richiesta di sostituzione |
| Il timeout lascia lo stato downstream sconosciuto | Prevenire un secondo effetto collaterale con lo stesso contratto di idempotenza | Interrogare la banca o la ferrovia autorevole, riconciliare lo stato accettato o assente, intensificare lo stato irrisolto | Timeout, chiave di idepotenza, risultato della richiesta, stato finale, incidente quando richiesto |
| Effetto a valle parziale o errato | Contenere nuovi tentativi, revocare l'autorizzazione al rilascio, aprire un incidente | Utilizzare il percorso di annullamento, richiamo, restituzione, risarcimento o riconciliazione manuale applicabile | Effetti impegnati, residuo, incidente, azioni di ripristino, risultato aziendale finale |
| Agente, credenziale, policy o compromissione dello screening | Disabilita l'agente, revoca le credenziali, nega le chiamate agli strumenti, blocca le code interessate | Individuare l'ambito della popolazione, riconciliare gli effetti a valle, ripristinare versioni e fonti attendibili, testare i controlli, approvare il riavvio | Risultati della revoca, esecuzioni interessate, indagine, riparazione, test, decisione di riavvio |
| Le prove richieste non possono essere scritte o sigillate | Bloccare o bloccare l'azione ai sensi del contratto di prova | Ripristinare i servizi di prova, riconciliare ogni richiesta interessata, sigillare i record completi prima del rilascio o chiuderli in caso di errore di controllo | Scrivi fallimento, popolazione interessata, riconciliazione, pacchetto completato o eccezione |
Conservare ed esportare le prove di rilascio dei pagamenti
Mantenere l'intera popolazione sotto una giurisdizione, conservazione legale, privacy e programma di registrazione approvati dall'organizzazione. Il manifesto del pacchetto di prove scaricabile elenca gli eventi e gli artefatti ordinati per un rilascio del pagamento. Collega inoltre entrambi gli esempi, lo schema pubblico e i passaggi di verifica offline per un singolo record e il sigillo manifest a livello di bundle.
Un pacchetto di prove sigillate dovrebbe contenere la prova dell'autenticità della fonte, il contesto del pagamento, i record di autorità e versione, la fonte e il risultato dello screening, ogni risultato del controllo dei pagamenti, i record di policy e approvazione, l'esatta ricevuta della chiamata allo strumento, l'esito bancario o ferroviario, la riconciliazione, gli incidenti o il recupero, la linea ordinata, il trattamento della privacy, i digest degli artefatti, gli hash dei record, le firme e i risultati della verifica.
Un esaminatore può convalidare lo schema JSON, ricalcolare gli hash di record e artefatti, verificare le firme, ricostruire l'ordine, testare che l'approvazione ha preceduto il rilascio, confermare che un'azione bloccata non ha raggiunto alcuno strumento, confrontare le chiavi di idempotenza con gli effetti a valle e riconciliare la ricevuta del pagamento con una fonte ottenuta in modo indipendente.
Lista di controllo per l'implementazione
Utilizza la lista di controllo per il rilascio dell'agente di pagamento della tesoreria per completare la progettazione del controllo per un'azione. Copre i pagamenti effettuati e l'autenticità della fonte; pagatore, beneficiario, beneficiario, conti, giurisdizioni, valuta e importo; identità e potestà delegata; accesso agli strumenti e confini dei dati; fonti di screening; regole di duplicazione, anomalia, velocità, cutoff e soglia; separazione dei compiti; azioni consentite e proibite; maker-checker e approvazione multipartitica; scadenza, riassegnazione ed escalation; risultati a valle; rifiuto, rollback, incidente e revoca; conservazione ed esportazione delle prove; e la firma finale.
- Istruzione di ambito uno. Indica la classe di pagamento, le persone giuridiche, i conti, le valute, le giurisdizioni, la ferrovia, lo scopo, l'agente, il richiedente, il proprietario, gli strumenti e il contratto di prova.
- Approva le regole di origine e contesto. Definisci canali autentici, campi obbligatori, origini di soggetti e account, aggiornamento dei dati, chiavi duplicate e trattamento della privacy.
- Approva le fonti di screening. Registra l'ambito legale applicabile, gli elenchi o i dati dei fornitori, aggiorna e sintetizza le regole, le entità selezionate, la politica di corrispondenza potenziale e il comportamento di interruzione.
- Pubblica fasce decisionali. Assegna a ogni condizione relativa a importo, controparte, qualità dei dati, anomalia, duplicazione, velocità, limite, valuta e percorso un risultato esplicito e un codice motivo.
- Test della separazione. Dimostra che il produttore non può approvare o rilasciare la richiesta trattenuta, che ogni controllore detiene l'autorità attuale e che il contesto modificato invalida l'approvazione.
- Verifica percorsi positivi e negativi. Convalida casi consentiti, avvisati, approvati, rifiutati, scaduti, bloccati, duplicati, interruzione, rifiuto ferroviario, esito sconosciuto, effetto parziale, revoca e ripristino.
- Verifica le prove offline. Convalida lo schema, gli hash, le firme, l'ordine degli eventi, i tempi di approvazione, le ricevute degli strumenti, lo stato downstream e i metadati di conservazione.
- Approvazione e revisione. Ottieni approvazioni di tesoreria, conformità alle sanzioni, criminalità finanziaria, IAM, operazioni di pagamento, tecniche, rischi e garanzie con una data di revisione successiva.
Come KLA implementa il percorso di controllo dei pagamenti della tesoreria
Il Piano di controllo dell'KLA ha fornito funzionalità di policy, approvazione, derivazione, audit e prova per le azioni degli agenti strumentate. Il KLA Policy Engine valuta la proposta di rilascio del Tesoro e la sua attuale identità, autorità, screening, importo, controparte, qualità dei dati, anomalia, duplicato, velocità, interruzione, valuta, percorso e contesto delle prove. Restituisce allow, warn, require_approval o block. Un risultato require_approval trattiene la chiamata associata e crea una Richiesta di decisione per Decision Desk. Un blocco impedisce alla chiamata di pagamento regolata di raggiungere il gateway della banca o il canale di pagamento.
Per le richieste decisionali sul piano di controllo, Decision Desk controlla l'autorizzazione decisionale, il ruolo di revisore richiesto, lo stato in sospeso, l'identità del richiedente e del produttore e il tempo dovuto. Impedisce ai richiedenti e ai creatori registrati di decidere la propria richiesta e rifiuta le azioni di approvazione o rifiuto dopo il tempo dovuto. Un controllore idoneo può inoltrare una richiesta scaduta. L'organizzazione deve fornire le identità dei produttori attuali, i ruoli richiesti, i tempi dovuti e prove complete di pagamento e screening su ogni percorso di produzione.
Lineage Explorer e Audit Trail espongono record di policy, decisioni umane, strumenti, esecuzione ed effetti a valle. Evidence Room può raggruppare i record selezionati in un Sealed Evidence Bundle con hash degli artefatti, firme e una radice Merkle che supporta i controlli di integrità offline.
La banca o il sistema ferroviario di pagamento esegue il pagamento e possiede il suo stato di regolamento. L'autorità responsabile dell'elenco delle sanzioni o il fornitore dello screening fornisce i dati dell'elenco e il servizio di corrispondenza. L'IAM della forza lavoro e i provider di identità del carico di lavoro autenticano persone, servizi e carichi di lavoro degli agenti. KLA fornisce la politica strumentata, il Decision Desk, il lignaggio, l'audit e il percorso di controllo delle prove attorno all'azione. L'organizzazione possiede ancora analisi legali e delle sanzioni, qualità degli elenchi e dello screening, classificazione dei pagamenti, completezza dei dati, soglie, competenza e personale dei revisori, amministrazione delle identità e dei diritti, connettività bancaria e ferroviaria, regole di liquidità e interruzione, conservazione, strumentazione completa, risposta agli incidenti, recupero e riconciliazione.
Riferimenti tecnici
Utilizzare questi contratti pubblici per verificare la richiesta di pagamento, l'esito della politica, l'approvazione, l'evento di audit, il manifesto delle prove e il record di esecuzione congiunta.
Fonti primarie e freschezza
Revisione della fonte completata 28 luglio 2026. Cambiano i programmi di sanzioni, le designazioni, i regolamenti, gli standard di pagamento, le regole sui pagamenti ferroviari e le politiche istituzionali. Ricontrolla la fonte in tempo reale, il programma applicabile, l'analisi legale locale e il regolamento bancario o ferroviario prima di utilizzare una decisione di controllo.
Per la giurisdizione degli Stati Uniti, il Servizio elenco sanzioni OFAC fornisce i dati attuali degli elenchi SDN e non SDN. Il Framework for OFAC Compliance Commitments dell'OFAC raccomanda un programma di conformità delle sanzioni basato sul rischio, costruito attorno all'impegno del management, alla valutazione del rischio, ai controlli interni, ai test e alle verifiche e alla formazione per le organizzazioni soggette alla giurisdizione degli Stati Uniti e ai relativi rapporti con l'estero. Le regole applicabili del programma OFAC determinano se un'organizzazione blocca, rifiuta, segnala o può elaborare una transazione.
Per l'ambito dell'Unione europea, la panoramica delle sanzioni e l'elenco consolidato delle sanzioni finanziarie della Commissione europea riflette gli atti giuridici adottati dell'UE e viene aggiornato secondo necessità. Il regolamento (UE) 2023/1113 si applica nell'ambito stabilito del trasferimento di fondi e delle cripto-attività laddove un fornitore coperto sia stabilito nell'Unione; riguarda le informazioni relative al pagatore, al beneficiario, al conto o all'identificativo della transazione, alla verifica, alle informazioni mancanti, ai controlli delle misure restrittive e alla conservazione. Il regolamento fornisce i requisiti legali per i fornitori coperti. Ogni organizzazione deve mappare il proprio ruolo legale e il percorso di pagamento.
Per le misure delle Nazioni Unite, l'Elenco consolidato del Consiglio di sicurezza delle Nazioni Unite aggrega le persone e le entità elencate. Gli Stati membri attuano le misure allegate a ciascun regime di sanzioni applicabile del Consiglio di sicurezza. L'organizzazione deve determinare l'implementazione e la misura nazionale rilevante per la sua giurisdizione e transazione.
A livello di standard internazionali, l’aggiornamento 16 della Raccomandazione FATF di giugno 2025 affronta le responsabilità nella catena dei pagamenti, le informazioni standardizzate sui pagamenti transfrontalieri e gli strumenti che proteggono da frodi ed errori; Il GAFI ha dichiarato che le modifiche riviste entreranno in vigore entro la fine del 2030. Le giurisdizioni implementano gli standard GAFI e ciascuna organizzazione stabilisce soglie di pagamento aziendale per il contesto legale, contrattuale, di rischio e di autorità applicabile.
Come guida di settore, gli Standard di trasparenza dei pagamenti Wolfsberg riguardano i pagamenti transfrontalieri e nazionali applicabili, i fornitori di servizi di pagamento partecipanti, le informazioni sulle parti coinvolte nei messaggi di pagamento e la capacità delle parti nella catena di monitorare e filtrare in modo efficace. I principi Wolfsberg sull'intelligenza artificiale e l'apprendimento automatico attribuiscono la responsabilità degli usi legati alla criminalità finanziaria all'istituto finanziario e affrontano lo scopo legittimo, l'uso proporzionato, la progettazione e la competenza tecnica, la responsabilità e la supervisione, nonché l'apertura e la trasparenza.
Per le entità finanziarie UE coperte, DORA, Regolamento (UE) 2022/2554 richiede un quadro documentato di gestione del rischio ICT, governance, resilienza, incidenti, test e controlli di terze parti nel suo ambito. Per un sistema di intelligenza artificiale che rientra nell’ambito di applicazione ad alto rischio della legge sull’intelligenza artificiale dell’UE, l’articolo 14 richiede un’efficace supervisione umana proporzionata al rischio, all’autonomia e al contesto, compresi il monitoraggio, l’interpretazione, l’override, l’inversione, l’intervento e le capacità di interruzione sicura. La classificazione del sistema e il ruolo giuridico determinano se si applica l'articolo 14.
Il modello a quattro risultati, le fasce di importo sintetiche, la progettazione del maker-checker, la mappatura degli eventi, gli esempi, l'elenco di controllo e il manifest del bundle presenti in questa guida sono modelli di implementazione. Non prevedono soglie legali, sanzionatorie, contabili, di liquidità o di pagamento universali.
Domande frequenti
Un agente AI può rilasciare un pagamento di tesoreria?
Un'organizzazione può autorizzare un agente di pagamento a inviare una liberatoria solo all'interno di un mandato esplicito, dopo che i controlli richiesti su fonte, identità, sanzioni, controparte, importo, qualità dei dati, anomalia, duplicato, velocità, interruzione, valuta e percorso restituiscono un risultato eseguibile. Le approvazioni umane richieste devono coprire le stesse istruzioni attuali.
Quali soggetti dovrebbero coprire lo screening delle sanzioni?
Selezionare i partiti e il percorso richiesto dalla politica legale e istituzionale applicabile. Il disegno di controllo registra comunemente il pagatore, il beneficiario, il beneficiario finale, le banche, gli intermediari, le giurisdizioni e i fatti rilevanti sulla proprietà o sul controllo, insieme alle fonti e alle versioni dell'elenco.
Come dovrebbe funzionare la separazione maker-checker per un agente di pagamento?
Registrare il preparatore del pagamento come produttore, instradare la richiesta vincolata a controllori idonei indipendenti, vietare al produttore e all'agente di decidere la propria richiesta, mantenere la modifica del campo separata dall'approvazione e consentire l'esecuzione del servizio di rilascio solo dopo che ogni decisione richiesta è stata presa.
Quando dovrebbe essere necessaria l'approvazione per un pagamento del Tesoro?
Richiedere l'approvazione per condizioni che esulano dall'autorità del produttore e rimangono entro l'autorità di un controllore idoneo, come importo configurato o fasce aggregate, un nuovo beneficiario, un conto modificato, un percorso a rischio elevato, un'anomalia, l'avvicinarsi del limite o altra eccezione materiale. I divieti legali e le violazioni assolute dell'autorità rimangono bloccate.
Cosa succede quando una schermata di sanzioni restituisce una potenziale corrispondenza?
Mantieni il pagamento non sbloccato in base alla regola di chiusura in caso di errore dell'organizzazione e instrada la partita verso un processo di aggiudicazione delle sanzioni qualificato quando la politica locale consente l'aggiudicazione. Conservare la fonte, la versione dell'elenco, gli input delle query, le prove di corrispondenza, l'autorità, la decisione, la motivazione e l'azione legale o operativa risultante.
Cosa succede quando scade l'approvazione del pagamento?
La scadenza invalida l'autorità di rilascio. Registra la richiesta di decisione scaduta con zero chiamate allo strumento di rilascio, aggiorna il contesto di screening e pagamento, valuta la politica attuale e crea una nuova richiesta quando il pagamento rimane ammissibile.
In cosa differiscono l'idempotenza e i controlli duplicati?
I controlli duplicati confrontano istruzioni commerciali, fatture, parti, conti, importi, date ed effetti precedenti. Una chiave di idempotenza vincola i tentativi di una chiamata allo strumento associato. Utilizza entrambi i controlli e riconcilia i risultati ambigui con la banca autorevole o la linea di pagamento.
Cosa dimostra che l'approvazione ha preceduto il rilascio del pagamento?
Utilizza ID evento e timestamp ordinati per richiesta, policy, approvazione, chiamata allo strumento e completamento. Associa l'azione e le prove presentate con i riepiloghi, l'autorità del revisore dei record e la scadenza, allega la ricevuta ferroviaria e verifica l'evento firmato e gli hash degli artefatti.
KLA fornisce elenchi di sanzioni o esegue pagamenti?
KLA governa un'azione strumentata attraverso policy, Decision Desk, lineage, audit e controlli delle prove. L'autorità sanzionatoria o il fornitore di screening selezionato fornisce i dati dell'elenco e lo screening. Il gateway della banca o la piattaforma di pagamento esegue e regola il pagamento. I provider di identità autenticano persone e carichi di lavoro.
Cosa fa parte di un pacchetto di prove di pagamento del Tesoro?
Includere autenticità della fonte, contesto del pagamento e della parte, identità e autorità, versioni dei componenti, fonti e risultati dello screening, risultati del controllo dei pagamenti, politica, ogni decisione umana, ricevuta dello strumento, risultato ferroviario, riconciliazione, incidenti o ripristino, derivazione ordinata, trattamento della privacy, conservazione, digest degli artefatti, hash dei record, firme e risultati della verifica.
Punti chiave
Un rilascio di pagamento governato dal Tesoro vincola un'istruzione autentica, il contesto completo della parte e del percorso, l'autorità dell'agente attuale, le sanzioni e i risultati del controllo dei pagamenti, le decisioni umane indipendenti, una chiamata bancaria o ferroviaria idempotente, il risultato a valle e prove verificabili. Inizia con l'elenco di controllo per il rilascio dell'agente di pagamento del Tesoro, convalida l'esempio approvato e l'esempio di blocco delle sanzioni rispetto allo schema pubblico e utilizzare il manifest del pacchetto di prove per la revisione offline.