> ## 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. # Stati KYT in Didit: transazione e caso > Riferimento per tutti gli stati di transazione, caso e Travel Rule in Didit. 1,000 transazioni al mese incluse, poi $0.001 ciascuna. Transaction Monitoring ha tre macchine a stati separate: la **transazione**, ogni **caso** e, ove applicabile, il **controllo Travel Rule**. Questa pagina è il riferimento. ## Stato della transazione Impostato alla creazione e aggiornato durante il ciclo di vita. | Stato | Significato | | - | - | | `APPROVED` | La transazione ha superato tutte le regole sotto la soglia di revisione. | | `IN_REVIEW` | Il punteggio ha superato la soglia di revisione, oppure una regola ha richiesto esplicitamente una revisione. Serve l'attenzione di un analista. | | `DECLINED` | Il punteggio ha superato la soglia di rifiuto, oppure una regola ha rifiutato esplicitamente. La transazione viene rifiutata. | | `AWAITING_USER` | L'utente deve agire prima che la transazione possa essere regolata. Didit imposta questo stato solo tramite una regola: l'azione `change_status` di una regola (per esempio la regola opt-in della libreria `travel-rule-pending-action`, che si attiva su un trasferimento Travel Rule in `ON_HOLD`), oppure un'azione di regola che ha richiesto una verifica aggiuntiva (è stata creata una sessione correttiva). Un trasferimento Travel Rule che richiede la prova del controllo del wallet non imposta da solo questo stato: la transazione mantiene lo stato assegnato dalle tue regole (di solito `APPROVED`) e il blocco `action_required` riporta l'URL per la verifica della proprietà del wallet ogni volta che una sessione widget è in attesa. Consulta il blocco `action_required` della transazione per l'azione concreta e l'URL. | ### Transizioni ```mermaid theme={null} stateDiagram-v2 [*] --> APPROVED: Score < review threshold, no blocking rules [*] --> IN_REVIEW: Score >= review threshold [*] --> DECLINED: Score >= decline threshold, or rule decline action [*] --> AWAITING_USER: Rule action change_status → AWAITING_USER IN_REVIEW --> APPROVED: Analyst cleared IN_REVIEW --> DECLINED: Analyst declined AWAITING_USER --> APPROVED: Remediation session approved AWAITING_USER --> DECLINED: Remediation session declined AWAITING_USER --> IN_REVIEW: Remediation session ended in review ``` Nota: al di fuori della Travel Rule non esiste alcuna transizione diretta da `APPROVED` o `DECLINED` verso altri stati. Alla scadenza di una Travel Rule, il tuo `timeout_outcome` imposta `IN_REVIEW` (`HOLD`) oppure `DECLINED` (`REJECT`) indipendentemente dallo stato attuale, e una regola che si attiva dopo una transizione Travel Rule può modificare una transazione `APPROVED`. Per le correzioni usa le patch di stato tramite la console; vengono registrate nel registro di audit. ## Alert Non esiste uno stato separato per gli alert. Un alert aperto è una transazione in `IN_REVIEW` o `AWAITING_USER`, quindi usa lo stato della transazione indicato sopra. Vedi [Alert](https://docs.didit.me/it/transaction-monitoring/alerts.md). ## Stato del caso Per tutti i dettagli consulta [Gestione dei casi](https://docs.didit.me/it/console/case-management/cases.md). | Stato | Significato | | - | - | | `OPEN` | In fase di indagine attiva. | | `AWAITING_USER` | In attesa dell'input dell'utente. | | `RESOLVED` | Chiuso con una risoluzione: `FALSE_POSITIVE`, `VALID_THREAT`, `INCONCLUSIVE`, `REQUIREMENTS_NOT_MET` oppure `REQUIREMENTS_SATISFIED`. | I casi hanno una **priorità** separata (`LOW`, `MEDIUM`, `HIGH`). ## Stato del controllo Travel Rule I trasferimenti di asset virtuali ai sensi della Travel Rule del FATF seguono uno **scambio a 13 stati** dedicato, separato dallo stato della transazione indicato sopra. Un trasferimento in uscita inizia con `AWAITING_COUNTERPARTY`, `NOT_APPLICABLE` (sotto `threshold_amount`), `UNCONFIRMED_OWNERSHIP` (wallet della controparte dichiarato in autocustodia), `COMPLETED` oppure `COUNTERPARTY_MISMATCHED_DATA` (una corrispondenza `INTERNAL` su un wallet verificato, in base alla corrispondenza del nome), `COUNTERPARTY_VASP_NOT_FOUND` oppure `COUNTERPARTY_VASP_NOT_REACHABLE`. Un trasferimento in entrata può anche iniziare con `ON_HOLD` oppure `NOT_ENOUGH_COUNTERPARTY_DATA`, e una registrazione sunrise che corrisponde a un wallet verificato, con un nome del beneficiario corrispondente o assente, passa direttamente da `COMPLETED` a `FINISHED`. Lo scambio termina in `FINISHED`, `CANCELLED` oppure `EXPIRED`. | Stato | Significato | | - | - | | `AWAITING_COUNTERPARTY` | Inviato alla controparte; in attesa della sua risposta. Un trasferimento inviato tramite TRUST resta in questo stato fino alla scadenza, perché TRUST non restituisce nulla che Didit possa leggere. In un'applicazione sandbox il trasferimento va al [Didit Test VASP](https://docs.didit.me/it/transaction-monitoring/travel-rule-sandbox.md), che risponde all'interno di Didit con lo scenario che scegli. | | `UNCONFIRMED_OWNERSHIP` | Assetto proprietario del wallet del beneficiario non ancora dimostrato. | | `ON_HOLD` | Didit lo imposta solo sui trasferimenti in entrata: una registrazione sunrise oppure una richiesta `TRP` in entrata il cui wallet non è nella tua rubrica degli indirizzi (oppure, per una richiesta basata solo sul nome, il cui nome non corrisponde a un unico titolare verificato), oppure una richiesta `TRP` in entrata che richiede una tua decisione manuale (l'accettazione automatica è disattivata, oppure la risposta automatica non è stata consegnata). Non cambia da solo lo stato della transazione; la regola opt-in della libreria `travel-rule-pending-action` imposta `AWAITING_USER`. Risolvilo con `POST /v3/transactions/{id}/travel-rule/ownership/`. | | `COMPLETED` | I dati dell'ordinante e del beneficiario corrispondono: è sicuro effettuare la trasmissione on-chain. | | `FINISHED` | Hash on-chain riportato; scambio chiuso. | | `CANCELLED` | Annullato da uno stato non terminale. | | `EXPIRED` | Il timeout di conferma è scaduto. Solo un trasferimento ancora in `AWAITING_COUNTERPARTY` alla sua scadenza scade; viene controllato ogni 15 minuti. Gli altri stati non scadono mai. Il tuo `timeout_outcome` viene applicato alla transazione, e questa modifica non invia alcun webhook `transaction.status.updated`. | | `COUNTERPARTY_MISMATCHED_DATA` | Il nome del beneficiario non corrisponde. | | `COUNTERPARTY_VASP_NOT_FOUND` | Nessun canale è riuscito a risolvere la controparte. | | `COUNTERPARTY_VASP_NOT_REACHABLE` | Controparte identificata, ma Didit non è riuscito a consegnare: il suo endpoint `TRP` non era raggiungibile oppure ha riportato un LEI diverso o mancante, oppure un nome diverso, oppure un canale di rete (GTR, TRUST, VerifyVASP, Sygna Bridge) non è riuscito a consegnare il messaggio. | | `COUNTERPARTY_VASP_GENERAL_DECLINE` | La controparte ha rifiutato lo scambio. | | `NOT_ENOUGH_COUNTERPARTY_DATA` | Una richiesta `TRP` in entrata non ha identificato il beneficiario né tramite il nome né tramite l'indirizzo. Non ha una scadenza e l'endpoint per la verifica dell'assetto proprietario non può risolverla, quindi annullala con `action: "cancel"`; il mittente non viene notificato. Didit non imposta mai questo stato su un trasferimento in uscita; compare lì solo se lo registri tu stesso, e puoi ritentare un trasferimento di questo tipo con `action: "resend"`. | | `NOT_APPLICABLE` | Sotto `threshold_amount`, quindi non è stato scambiato nulla, oppure un valore che hai registrato su un trasferimento su cui Didit non esegue la Travel Rule (Travel Rule disabilitata, transazione il cui tipo non è `travelRule`, oppure un valore legacy). | Le integrazioni più datate possono ancora inviare i valori legacy `UNKNOWN`, `COMPLIANT`, `PENDING_ACTION`, `PENDING_COUNTERPARTY`, `FAILED` e `EXEMPT`; Didit li converte automaticamente negli stati indicati sopra. Per il riferimento ufficiale consulta [Travel Rule](https://docs.didit.me/it/transaction-monitoring/travel-rule.md#ciclo-di-vita). ## Stato del risultato del provider Ogni risultato di un provider esterno (screening dei wallet, monitoraggio fiat, screening delle sanzioni) viene memorizzato con un proprio stato. Viene esposto in `provider_results[]` nella risposta della transazione. | Stato | Significato | | - | - | | `PENDING` | Interrogazione del provider in corso. | | `COMPLETED` | Risultato restituito correttamente. | | `FAILED` | Si è verificato un errore del provider oppure è scaduto il tempo limite. | | `SKIPPED` | Provider ignorato intenzionalmente (ad esempio, transazione sotto la soglia). | ## Esiti delle esecuzioni delle regole Ogni `TransactionRuleRun` contiene: * `matched` (booleano): la regola è stata attivata? * `is_test` (booleano): la regola era in modalità TEST? * `mode`: `ACTIVE`, `DISABLED` o `TEST` al momento della valutazione. * `score_delta`: contributo al punteggio (se la regola ha avuto esito positivo ed è attiva). * `status_target`: lo stato richiesto dalla regola (se l'azione è `change_status`). Per la struttura delle regole, vedi [Regole](https://docs.didit.me/it/transaction-monitoring/rules.md). ## Codici di motivazione della decisione Valori `reason` comuni nelle transizioni di stato: | Motivo | Significato | | - | - | | `rule_score_threshold` | Il punteggio ha superato la soglia di revisione o di rifiuto. | | `rule_change_status` | L'azione `change_status` di una regola ha forzato uno stato. | | `analyst_approved` / `analyst_declined` / `analyst_cleared` | Azione manuale dell'analista. | | `user_action_approved` / `user_action_declined` / `user_action_in_review` | Esito della sessione di risoluzione collegata (l'azione dell'utente richiesta mentre lo stato è `AWAITING_USER`). | | `provider_update` | Il provider esterno ha aggiornato il risultato. | | `aml_confirmed_sanction` | Lo screening AML ha confermato una corrispondenza con le sanzioni. | | `blocklist_applicant` / `blocklist_counterparty` | Applicazione della blocklist a un soggetto. | ## Passaggi successivi > [card] [Punteggio di rischio](https://docs.didit.me/it/transaction-monitoring/risk-scoring.md) > > Come i punteggi vengono associati agli stati. > [card] [Alert](https://docs.didit.me/it/transaction-monitoring/alerts.md) > > Ciclo di vita degli alert. > [card] [Casi](https://docs.didit.me/it/transaction-monitoring/cases.md) > > Ciclo di vita dei casi. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.