> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

# Revisione 4-Eyes: approvazione maker/checker

> Didit richiede a un secondo responsabile di approvare o rifiutare ogni decisione, con l'esito in attesa di un revisore diverso.

La revisione a 4 occhi aggiunge una seconda approvazione indipendente prima che una risoluzione abbia effetto, un controllo standard di separazione delle funzioni per le indagini a rischio più elevato.

***

## Configurazione

Nel blueprint maker, imposta **Revisione a 4 occhi** su un **blueprint checker**. L'impostazione di questo campo attiva la revisione a 4 occhi per il blueprint maker: non esiste un interruttore separato.

## Come funziona

1. Un agente nel blueprint maker risolve un caso come di consueto (falso positivo o minaccia reale, più una nota se richiesta).
2. Invece di chiudere il caso, lo stato resta **Aperto**, la risoluzione proposta viene messa in attesa e il caso passa nella coda del **blueprint checker**. La cronologia del caso registra `Submitted for approval`.
3. Un checker esamina la scheda Panoramica del caso, dove un banner di doppio controllo mostra le azioni **Approva** e **Rifiuta**.
4. **Approva** applica la risoluzione in attesa: il caso diventa **Risolto** con la risoluzione e la nota originali, attribuito all'agente che l'ha inviata. La cronologia registra `Approval granted` e poi `Resolved`.
5. **Rifiuta** annulla la risoluzione in attesa e riporta il caso nel **blueprint maker**. La cronologia registra `Approval rejected` e il maker riceve una notifica.

> [!WARNING]
>
> L'agente che ha inviato la risoluzione non può approvarla o rifiutarla da sé: la regola è applicata lato server. Il tentativo restituisce un 403. (Approvare o rifiutare un caso senza una risoluzione in attesa di approvazione restituisce un 409.)

## Designare il checker

L'agente che risolve può indicare il membro che deve approvare la risoluzione, tramite il campo `checker` della [API di risoluzione dei casi](https://docs.didit.me/it/management-api/cases/resolve.md).
Solo quel membro può poi approvarla o rifiutarla; chiunque altro, compresa una chiave API, riceve un 403.
Il campo `checker` del caso mostra il membro indicato finché la risoluzione non viene approvata, rifiutata o restituita per una nuova revisione.
Senza un checker indicato, la risoluzione resta in attesa nella coda del blueprint checker, come descritto sopra.
Il checker indicato deve avere accesso ai casi dell'applicazione e non può essere l'agente che ha inviato la risoluzione.

## Quando cambiano le evidenze

La modifica di una risposta della checklist, o l'aggiunta o la rimozione di una verifica o di una transazione collegata, annulla la decisione in attesa e riporta il caso alla politica di revisione originale.
La cronologia delle attività registra che è necessaria una nuova decisione di revisione e conserva la proposta precedente nell'evento di audit.
Il revisore deve esaminare le evidenze aggiornate e inviare una nuova decisione prima che un secondo agente possa approvarla.
Ripetere la stessa risposta della checklist non annulla una revisione in attesa.

L'approvazione verifica anche che le evidenze della fonte collegate corrispondano a quelle inviate per la revisione.
Uno stato di verifica modificato, un campo del documento che è stato corretto, delle evidenze di transazione cambiate o una fonte non disponibile bloccano l'approvazione con `409`.
Perdere l'accesso alle evidenze della rete globale collegate tramite un Fraud Check richiede anch'esso una nuova revisione.
Usa **Rifiuta** per riportare il caso al maker, esaminare le evidenze aggiornate e inviare una nuova decisione.
Aprire il record di origine o aggiungere una nota interna al caso non blocca di per sé una revisione invariata.
Se le evidenze inviate non possono essere verificate, prima dell'approvazione è necessaria una nuova revisione.

## Note

* I requisiti di revisione vengono salvati quando il caso viene aperto.
  Il passaggio alla coda del checker non sostituisce questi requisiti con eventuali modifiche successive alla politica.
* Un caso può avere una sola risoluzione in attesa alla volta; richiedere ulteriori informazioni (**In attesa dell'utente**) è bloccato finché una risoluzione è in attesa di approvazione.
* La revisione a 4 occhi si abbina alle [note di risoluzione obbligatorie](https://docs.didit.me/it/console/case-management/blueprints.md#impostazioni-generali): attiva entrambe per i blueprint a rischio più elevato, così da richiedere sia una motivazione documentata sia un secondo revisore.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.