> ## 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.

# Schema risposta transazioni KYT: riferimento payload

> Risposta KYT di Didit annotata: punteggio, regole, parti, dispositivo e IP, screening, Travel Rule. 1,000 al mese incluse, poi $0.001 ciascuna.

Questa pagina descrive il payload completo restituito da `POST /v3/transactions/` e `GET /v3/transactions/{transaction_id}/`. Entrambi gli endpoint restituiscono lo stesso oggetto `TransactionDetail`; il [riferimento API](https://docs.didit.me/it/management-api/transactions/get.md) riporta lo schema campo per campo, mentre questa pagina ne illustra la struttura.

## Struttura di primo livello

```json theme={null}
{
  "uuid": "abcdef12-3456-4890-abcd-ef1234567890",
  "environment": "live",
  "transaction_number": 4123,
  "txn_id": "tx-0001",
  "txn_date": "2026-04-16T12:00:00Z",
  "zone_id": "Europe/Madrid",
  "transaction_type": "finance",
  "action_type": "withdrawal",
  "direction": "OUTBOUND",
  "status": "IN_REVIEW",
  "source": "LIVE",
  "amount": "12500",
  "currency": "EUR",
  "currency_type": "fiat",
  "amount_in_default_currency": null,
  "default_currency_code": null,
  "preferred_currency_amount": "13520.75",
  "preferred_currency_code": "USD",
  "payment_details": "Withdrawal to bank account",
  "payment_txn_id": null,
  "score": 65,
  "severity": "MEDIUM",
  "decision_reason_code": "rule_score_threshold",
  "decision_reason_label": "Score above review threshold",
  "vendor_data": "user-42",
  "metadata": { "subject": { ... }, "counterparty": { ... } },
  "props": { "order_id": "ORD-7891" },
  "tags": [ ... ],
  "parties": [ ... ],
  "payment_methods": [ ... ],
  "documents": [ ... ],
  "activities": [ ... ],
  "alerts": [],
  "rule_runs": [ ... ],
  "provider_results": [ ... ],
  "travel_rule": { ... } | null,
  "network_snapshot": { ... } | null,
  "remediation": { ... } | null,
  "action_required": { ... } | null,
  "cost_breakdown": { ... } | null
}
```

Due identificatori descrivono la stessa transazione. `uuid` è l'identificatore stabile di Didit e va indicato nel percorso di `GET /v3/transactions/{transaction_id}/`; `txn_id` è il `transaction_id` che hai fornito al momento della creazione. `transaction_number` è il numero sequenziale, valido nell'ambito dell'applicazione, che la console mostra.

Il soggetto e la controparte che hai inviato non compaiono come chiavi di primo livello. Sono le voci dell'array `parties`, distinte dal campo `role`, mentre `vendor_data` di primo livello è una copia di comodo del `vendor_data` dell'utente.

## Campi principali

### Campi finanziari

* `amount` / `currency`: importo della transazione così come inviato. `amount` è una stringa decimale senza zeri finali (`"1500"`, `"0.5"`), con fino a 18 cifre decimali.
* `currency_type`: `fiat` o `crypto`, come inviato in `currency_kind`; `null` se omesso.
* `amount_in_default_currency` / `default_currency_code`: l'importo già convertito che hai fornito nella richiesta, restituito così com'è; `null` se non lo hai inviato.
* `preferred_currency_amount` / `preferred_currency_code`: `amount` convertito nella valuta preferita della tua applicazione. `null` quando non è disponibile un tasso di cambio per `currency` e non hai inviato `amount_in_default_currency`.
* `payment_details` / `payment_txn_id`: il riferimento di pagamento in testo libero e il riferimento esterno del pagamento (ad esempio un hash di transazione blockchain) presenti nella richiesta.

### Campi di stato

* `status`: `APPROVED`, `IN_REVIEW`, `DECLINED`, `AWAITING_USER`. Le transazioni vengono create come `APPROVED`; le regole possono cambiarle in modo sincrono.
* `score`: punteggio di rischio intero accumulato dalle regole. Un valore più alto indica un rischio maggiore.
* `severity`: `UNKNOWN`, `LOW`, `MEDIUM`, `HIGH`, `CRITICAL`, oppure `null` finché una regola o un provider non lo imposta.
* `decision_reason_code` / `decision_reason_label`: motivo strutturato e motivo leggibile dello stato attuale.
* `environment`: `live` o `sandbox`, in base all'applicazione a cui appartiene la transazione. Una transazione `sandbox` viene memorizzata ma non viene mai valutata, quindi il suo `rule_runs` vuoto significa "non valutata" e non "nessuna corrispondenza". Vedi [Monitoraggio delle transazioni in sandbox](https://docs.didit.me/it/integration/sandbox-testing.md#monitoraggio-delle-transazioni-nella-sandbox).
* `source`: `LIVE` per le transazioni inviate tramite API o SDK, `IMPORTED` per le transazioni caricate tramite importazione CSV dalla console.

### Parti

Ogni parte della transazione è una voce di `parties`. L'endpoint di creazione registra il soggetto come `APPLICANT` e la controparte facoltativa come `COUNTERPARTY`; l'enum `role` include anche `REMITTER` e `BENEFICIARY`. Tutte le voci hanno la stessa struttura.

```json theme={null}
"parties": [
  {
    "uuid": "b1111111-2222-4333-8444-555555555555",
    "role": "APPLICANT",
    "entity_type": "individual",
    "kind": "USER",
    "vendor_data": "user-42",
    "full_name": "John Doe",
    "first_name": "John",
    "last_name": "Doe",
    "country_code": "USA",
    "dob": "1990-01-01",
    "address": { "line_1": "...", "city": "...", "country": "USA" },
    "institution_info": { "name": "...", "country_code": "..." },
    "device": {
      "fingerprint": "...",
      "persistent_device_id": "...",
      "user_agent": "...",
      "browser_family": "Chrome",
      "browser_version": "131.0",
      "platform": "web",
      "os_family": "Windows",
      "os_version": "10.0",
      "accept_language": "en-US,en;q=0.9",
      "session_id": "...",
      "session_age_ms": 84000,
      "metadata": {
        "accept_language": "en-US,en;q=0.9",
        "session_id": "...",
        "session_age_ms": 84000
      },
      "network_context": {
        "ip_address": "203.0.113.5",
        "ip_country": "United States",
        "ip_country_code": "US",
        "ip_state": "California",
        "ip_city": "San Francisco",
        "latitude": 37.7749,
        "longitude": -122.4194,
        "isp": "Example ISP",
        "organization": "Example Org",
        "is_vpn_or_tor": false,
        "is_data_center": false,
        "time_zone": "America/Los_Angeles",
        "time_zone_offset": "-0700",
        "asn_number": 64496,
        "asn_organization": "Example ISP",
        "connection_type": "isp",
        "carrier": null,
        "proxy_type": null
      }
    },
    "external_party_snapshot": null
  },
  {
    "uuid": "c2222222-3333-4444-8555-666666666666",
    "role": "COUNTERPARTY",
    "entity_type": "company",
    "kind": "EXTERNAL",
    "vendor_data": null,
    "full_name": "Acme Supplier",
    "first_name": null,
    "last_name": null,
    "country_code": "GBR",
    "dob": null,
    "address": {},
    "institution_info": {},
    "device": {},
    "external_party_snapshot": { "full_name": "Acme Supplier", "country": "GBR", "...": "..." }
  }
]
```

* `role`: `APPLICANT`, `COUNTERPARTY`, `REMITTER`, `BENEFICIARY`. Filtra su questo campo per trovare il soggetto.
* `entity_type`: `individual`, `company`, `external`, `unhostedWallet`, come inviato.
* `kind`: `USER` o `BUSINESS` quando la parte è collegata a un utente o a un'azienda di Didit tramite `vendor_data`; `EXTERNAL` in caso contrario.
* `country_code` / `dob`: dal campo `address.country` e da `date_of_birth` inviati.
* `address` / `institution_info`: gli oggetti così come inviati; `{}` se omessi.
* `external_party_snapshot`: copia congelata dei dati della parte per le parti `EXTERNAL`; `null` finché la parte è collegata a un utente o a un'azienda di Didit.

#### `device`

`device` è il `device_context` che hai inviato per quella parte, normalizzato in snake\_case, con l'arricchimento IP lato server. È `{}` quando la richiesta non conteneva alcun contesto del dispositivo, quindi tratta sempre ogni chiave come facoltativa.

| Chiave | Descrizione |
| - | - |
| `fingerprint`, `persistent_device_id` | Identificatori del dispositivo così come inviati. |
| `user_agent`, `browser_family`, `browser_version`, `platform`, `os_family`, `os_version` | Attributi di browser e sistema operativo così come inviati. `browser_family` e `platform` non vengono mai derivati da `user_agent`. |
| `accept_language`, `session_id`, `session_age_ms` | Attributi di sessione così come inviati. Vengono anche riportati in `device.metadata` con gli stessi nomi, ed è lì che il percorso SDK li memorizza. |
| `metadata` | Presente quando la richiesta includeva un oggetto `metadata` o uno dei tre attributi di sessione. |
| `network_context` | Contesto di rete, vedi sotto. Assente quando non sono stati inviati dati di IP o di rete. |

Non esiste un oggetto di arricchimento separato. Quando la parte include un `network_context.ip_address` pubblico, Didit lo risolve direttamente e scrive i [campi arricchiti](https://docs.didit.me/it/transaction-monitoring/ip-enrichment.md#campi-arricchiti) nello stesso oggetto `network_context`, compilando solo le chiavi che non hai fornito. Le chiavi per cui il resolver ha restituito valori vuoti vengono omesse, quindi un `network_context` completamente arricchito contiene le quattro chiavi inviate (`ip_address`, `ip_country_code`, `latitude`, `longitude`) più quelle tra `ip_country`, `ip_state`, `ip_city`, `isp`, `organization`, `is_vpn_or_tor`, `is_data_center`, `time_zone`, `time_zone_offset`, `asn_number`, `asn_organization`, `connection_type`, `carrier` e `proxy_type` che sono state risolte. `is_vpn_or_tor` e `is_data_center` sono sempre presenti dopo una risoluzione riuscita.

L'arricchimento viene saltato e `network_context` viene restituito esattamente come inviato quando l'IP manca o non è instradabile, quando l'applicazione è in sandbox o quando la risoluzione non è riuscita. `ip_country_code` è un codice ISO 3166-1 alpha-2 quando Didit lo ha risolto, altrimenti è il valore che hai inviato; le condizioni delle regole normalizzano entrambe le forme prima del confronto.

### Metodi di pagamento

```json theme={null}
"payment_methods": [
  {
    "uuid": "...",
    "payment_method_type": "bank_account",
    "label": null,
    "fingerprint": "9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08",
    "account_id": "DE89370400440532013000",
    "issuing_country": "DE",
    "owner_kind": "USER",
    "vendor_data": "user-42",
    "owner_name": "John Doe",
    "institution_info": {},
    "details": { "method_type": "bank_account", "account_id": "DE89370400440532013000", "issuing_country": "DE" },
    "external_owner_snapshot": null,
    "role": "SOURCE"
  }
]
```

* `role`: `SOURCE`, `DESTINATION`, `FUNDING`, `BENEFICIARY`. L'endpoint di creazione assegna `SOURCE` / `DESTINATION` in base a `direction`: in una transazione in uscita il metodo del soggetto è `SOURCE` e quello della controparte è `DESTINATION`; in una transazione in entrata è l'inverso.
* `payment_method_type`: `bank_card`, `bank_account`, `e_wallet`, `crypto_wallet`, `unhosted_wallet`, `other`.
* `fingerprint`: SHA-256 calcolato su `type:account_id:issuing_country`, stabile tra le transazioni, così puoi correlare il riutilizzo dello stesso strumento. `null` quando non è stato inviato alcun `account_id`.
* `owner_kind` / `vendor_data` / `owner_name`: chi è il proprietario dello strumento, con la stessa convenzione `USER` / `BUSINESS` / `EXTERNAL` usata per le parti.
* `details`: l'oggetto `payment_method` grezzo così come inviato.

### Esecuzioni delle regole

```json theme={null}
"rule_runs": [
  {
    "uuid": "...",
    "rule": "f6a7b8c9-0123-4def-b012-3456789abcde",
    "rule_title": "High-value outbound",
    "rule_description": null,
    "rule_category": "finance",
    "matched": true,
    "is_test": false,
    "mode": "ACTIVE",
    "severity": "MEDIUM",
    "score_delta": 30,
    "status_target": null,
    "action_summary": "score +30",
    "metadata": {
      "scope_match": true,
      "conditions": [
        {
          "field": "amount",
          "operator": "gt",
          "expected_value": "10000",
          "current_value": "12500",
          "matched": true,
          "group_index": null,
          "group_logic": "AND",
          "field_source": null
        }
      ],
      "aggregations": []
    },
    "created_at": "2026-04-16T12:00:01Z"
  },
  {
    "uuid": "...",
    "rule": "...",
    "rule_title": "High-risk jurisdiction counterparty",
    "rule_description": null,
    "rule_category": "finance",
    "matched": true,
    "is_test": false,
    "mode": "ACTIVE",
    "severity": "HIGH",
    "score_delta": 35,
    "status_target": "IN_REVIEW",
    "action_summary": "score +35; change_status:IN_REVIEW; add_tag:high_risk_country",
    "metadata": { "scope_match": true, "conditions": [ ... ], "aggregations": [] },
    "created_at": "2026-04-16T12:00:01Z"
  }
]
```

* `rule`: UUID della regola eseguita; `rule_title`, `rule_description`, `rule_category` vengono copiati da essa.
* `matched`: un'esecuzione viene registrata solo quando le condizioni della regola sono soddisfatte, quindi le valutazioni live riportano sempre `matched: true`. Le regole valutate senza corrispondenza non lasciano alcuna voce. I dati di esempio possono includere righe con `matched: false`.
* `is_test` / `mode`: `true` e `TEST` quando la regola è stata eseguita in modalità test; un'esecuzione di test viene registrata ma non ha effetti su `status`, `score` o `severity`.
* `score_delta` / `status_target` / `severity`: il contributo di questa esecuzione. `status_target` viene impostato quando è stata eseguita un'azione `change_status` oppure quando il punteggio aggiunto ha superato una [soglia](https://docs.didit.me/it/transaction-monitoring/risk-scoring.md).
* `action_summary`: riepilogo testuale delle azioni eseguite dalla regola, unite con `; ` (`score +30`, `change_status:IN_REVIEW`, `add_tag:<name>`, `add_note`, `add_to_list`, `open_case`); `null` quando la regola non ha eseguito alcuna azione.
* `metadata`: il dettaglio della valutazione: `scope_match`, più `conditions[]` e `aggregations[]`. Le due liste usano chiavi di valore diverse:
  * `conditions[]`: una voce per condizione, con `field`, `operator`, `expected_value`, il `current_value` letto dalla transazione, `matched`, `group_index` e `group_logic`. `field_source` è sempre `null` nelle esecuzioni delle regole sulle transazioni; viene classificato solo per gli [eventi di monitoraggio](https://docs.didit.me/it/transaction-monitoring/events.md).
  * `aggregations[]`: una voce per ogni aggregazione di frequenza, conteggio o somma, con `metric`, `field`, `operator`, `expected_value`, il `computed_value` risultante dalla valutazione dell'aggregazione, `window`, `filters`, `matched` e `sample_references`. Le aggregazioni che possono essere calcolate solo in modo asincrono riportano `computed_value: null` e `deferred: true`.

### Alert

`alerts` è oggi sempre un array vuoto.
Un alert aperto corrisponde a una transazione trattenuta, quindi leggi invece `status` (`IN_REVIEW` o `AWAITING_USER`). Vedi [Alert](https://docs.didit.me/it/transaction-monitoring/alerts.md).

### Attività

Il registro delle attività della transazione: creazione, note, revisioni manuali e modifiche di stato.

```json theme={null}
"activities": [
  {
    "uuid": "...",
    "activity_type": "TRANSACTION_CREATED",
    "source": "TRANSACTION",
    "status": "APPROVED",
    "title": "withdrawal",
    "description": null,
    "metadata": { "action_type": "withdrawal", "direction": "OUTBOUND", "amount": "12500", "currency": "EUR" },
    "occurred_at": "2026-04-16T12:00:00Z"
  }
]
```

Le note dell'analista compaiono qui come voci `TRANSACTION_NOTE_ADDED`; non esiste un array `notes` separato.

### Documenti

File allegati alla transazione dalla console. `[]` se non ce ne sono.

```json theme={null}
"documents": [
  {
    "uuid": "...",
    "label": "Invoice",
    "note": null,
    "uploaded_by": "...",
    "created_at": "2026-04-16T12:05:00Z",
    "files": [
      { "uuid": "...", "file_url": "https://...", "original_filename": "invoice.pdf", "file_size": 48213 }
    ]
  }
]
```

`file_url` è un URL firmato a breve scadenza; recuperalo quando ti serve invece di memorizzarlo.

### Risultati dei provider

Output di provider esterni (screening dell'hash della transazione, screening dei wallet, monitoraggio fiat, screening delle sanzioni).

```json theme={null}
"provider_results": [
  {
    "uuid": "...",
    "result_type": "TRANSACTION_SCREENING",
    "provider": "merklescience",
    "status": "SCREENED",
    "severity": "HIGH",
    "score": 82,
    "summary": "Merkle Science risk: High (4/5). Dominant risk: stolen_funds. Driven by: 50% direct incoming exposure to Theft / Hack (Stolen Funds)",
    "payload": {
      "provider": "merklescience",
      "screening_type": "TRANSACTION_SCREENING",
      "transaction_hash": "0x...",
      "wallet_address": null,
      "blockchain": "ETH",
      "block_timestamp": "2026-04-01T00:07:11Z",
      "total_value_usd": 2942.31,
      "fee_usd": 0.09,
      "transaction_flows": [
        {
          "flow_type": "token",
          "from_address": "0x...",
          "to_address": "0x...",
          "amount": 72.83039728,
          "amount_usd": 235.97,
          "currency": "UNI",
          "token_name": "Uniswap",
          "token_address": "0x1f9840a85d5af5bf1d1762f925bdaddc4201f984",
          "transaction_hash": "0x...",
          "block_timestamp": "2026-04-01T00:07:11Z",
          "index": 460,
          "success": true,
          "metadata": {
            "provider": "blockscout",
            "token_type": "ERC-20",
            "token_icon_url": "https://...",
            "token_reputation": "ok",
            "token_holders_count": "410093",
            "from": {
              "label": "ravaga.eth",
              "tags": [{ "name": "Beacon Depositor", "type": "generic" }]
            },
            "to": {
              "label": "AirSwap: Spender",
              "is_contract": true,
              "is_verified": true
            }
          }
        }
      ],
      "source_of_funds": [
        {
          "category": "stolen_funds",
          "entity_name": "Stolen Funds",
          "entity_type": "Theft",
          "entity_subtype": "Hack",
          "exposure_direction": "incoming",
          "exposure_type": "direct",
          "is_direct": true,
          "amount_usd": 1471.16,
          "percentage": 50,
          "country": ""
        }
      ],
      "destination_of_funds": [],
      "counterparty_connections": [],
      "sanctions_hit": false,
      "risk_factors": [
        {
          "source": "exposure",
          "category": "stolen_funds",
          "label": "Theft / Hack",
          "entity_name": "Stolen Funds",
          "direction": "incoming",
          "exposure_type": "direct",
          "amount_usd": 1471.16,
          "percentage": 50,
          "is_high_risk": true,
          "description": "50% direct incoming exposure to Theft / Hack (Stolen Funds)"
        }
      ],
      "raw_response": { "...": "provider-specific details" }
    },
    "created_at": "2026-04-16T12:00:02Z"
  }
]
```

`result_type`: `FIAT_MONITORING`, `WALLET_SCREENING`, `TRANSACTION_SCREENING`, `TRAVEL_RULE`, `NETWORK_GRAPH`, `CUSTOM`.

`payload.risk_factors` è la spiegazione ordinata di `score`: indica cosa ha prodotto il verdetto, prima i fattori ad alto rischio e poi in base al valore trasferito. Un `score` alto senza alcuna voce `is_high_risk` significa che il provider ha valutato l'entità con il proprio modello di esposizione senza segnalare una corrispondenza con sanzioni o con un'entità attribuita; `summary` lo dichiara esplicitamente. Riferimento campo per campo: [Fattori di rischio](https://docs.didit.me/it/transaction-monitoring/wallet-screening.md#fattori-di-rischio). I risultati sottoposti a screening prima dell'introduzione di questo campo non includono la chiave.

Per lo screening crittografico dell'hash delle transazioni, `transaction_flows` è popolato quando è disponibile l'arricchimento on-chain. Normalizza l'attività della catena in modo che la console possa mostrare sia la panoramica della transazione sia il grafo di visualizzazione a partire dallo stesso payload di risposta.

Fonti di arricchimento supportate:

* Le catene EVM usano Blockscout per normalizzare la transazione principale, le chiamate interne e i trasferimenti di token.
* Bitcoin usa mempool.space per normalizzare input e output della transazione.
* Solana usa Helius per normalizzare i trasferimenti nativi di SOL, i trasferimenti di token SPL e il contesto disponibile per gli eventi NFT.

Ogni elemento `transaction_flows[]` include campi normalizzati stabili (`flow_type`, `from_address`, `to_address`, `amount`, `amount_usd`, `currency`, `token_name`, `token_address`, `transaction_hash`, `block_timestamp`, `index`, `success`) più `metadata` specifici del provider.

Esempi comuni di `metadata`:

```json theme={null}
{
  "provider": "blockscout",
  "decoded_method_call": "swap(string aggregatorId, address tokenFrom, uint256 amount, bytes data)",
  "block_number": 23141214,
  "gas_used": "171843",
  "fee_native": 0.000342317619518133,
  "token_icon_url": "https://...",
  "token_reputation": "ok"
}
```

```json theme={null}
{
  "provider": "mempool",
  "role": "input",
  "previous_txid": "4c0c...",
  "previous_vout": 0,
  "scriptpubkey_type": "v0_p2wpkh",
  "fee_btc": 0.00000322,
  "block_height": 943130
}
```

```json theme={null}
{
  "provider": "helius",
  "source": "MAGIC_EDEN",
  "type": "NFT_BID",
  "description": "Wallet bid 2.5 SOL on an NFT.",
  "slot": 136658192,
  "fee_sol": 0.000005,
  "nft_event": {
    "type": "NFT_BID",
    "source": "MAGIC_EDEN",
    "nft_mints": ["3bUW..."]
  }
}
```

`metadata` può contenere campi aggiuntivi e varia in base al provider. Non costruire integrazioni critiche che richiedano la presenza di ogni chiave per ogni catena.

### Travel Rule

`null` quando la transazione non ha alcun trasferimento o controllo Travel Rule. Viene popolato quando invii `travel_rule_details`, e anche quando [Travel Rule](https://docs.didit.me/it/transaction-monitoring/travel-rule.md) è abilitata per l'applicazione e la transazione è stata creata con `transaction_category: "travelRule"`: in tal caso Didit avvia lo scambio autonomamente, con o senza `travel_rule_details`, e ne riporta qui lo `status`. Leggi questo campo invece della richiesta che hai inviato.
Su un trasferimento in entrata, i dati `originator_data` e `beneficiary_data` della controparte restano mascherati (`data_masked: true`) finché non viene confermata la proprietà del wallet (vedi [Dati della controparte mascherati](https://docs.didit.me/it/transaction-monitoring/travel-rule.md#dati-della-controparte-mascherati)).

```json theme={null}
"travel_rule": {
  "uuid": "...",
  "status": "COMPLETED",
  "required": true,
  "protocol": "TRP",
  "obligations_count": 2,
  "originator_data": { "name": "...", "wallet_address": "..." },
  "beneficiary_data": { "name": "...", "wallet_address": "..." },
  "metadata": {},
  "direction": "OUTBOUND",
  "rail": "TRP",
  "counterparty_vasp": null,
  "delivery": {
    "kind": "SEND",
    "status": "DELIVERED",
    "rail": "TRP",
    "attempts": 1,
    "last_error": "",
    "next_attempt_at": null,
    "delivered_at": "..."
  },
  "discovery": [ ... ],
  "reason": "",
  "next_actions": []
}
```

`direction`, `rail`, `counterparty_vasp`, `delivery`, `discovery`, `reason` e `next_actions` hanno la stessa struttura dell'endpoint dei trasferimenti.
`reason` e `next_actions` indicano perché un trasferimento con `COUNTERPARTY_VASP_NOT_FOUND` o `COUNTERPARTY_VASP_NOT_REACHABLE` è bloccato e cosa lo fa proseguire; valgono `""` e `[]` per qualsiasi altro stato: vedi [Perché un trasferimento è bloccato](https://docs.didit.me/it/transaction-monitoring/travel-rule.md#perché-un-trasferimento-è-bloccato).
Ogni riga di [`GET /v3/transactions/`](https://docs.didit.me/it/management-api/transactions/list) contiene lo stesso blocco.

Vedi [Travel Rule](https://docs.didit.me/it/transaction-monitoring/travel-rule.md).

### Snapshot della rete

Il grafo memorizzato stesso, non un riferimento ad esso. Proviene da una delle due fonti:

* un `network_snapshot` che hai inviato con la transazione, oppure
* il grafo che Didit costruisce quando lo [Screening AML dei wallet](https://docs.didit.me/it/transaction-monitoring/aml-screening.md) va a buon fine per una transazione crypto, anche se la richiesta non conteneva alcun `network_snapshot`. Un grafo costruito dallo screening sostituisce quello inviato, e un nuovo screening asincrono lo aggiorna.

`null` quando non esiste nessuno dei due:

```json theme={null}
"network_snapshot": {
  "uuid": "...",
  "nodes": [ ... ],
  "edges": [ ... ],
  "metrics": { }
}
```

La pagina di dettaglio della transazione nella console mostra lo stesso grafo.

### Tag, metadata, props

* `tags[]`: tag associati (tramite un'azione di una regola o da un analista): `{ "uuid", "name", "color", "description", "source" }`, dove `source` è `didit` per un tag predefinito e `custom` per uno dei tuoi.
* `metadata`: uno snapshot dei payload `subject` e `counterparty` esattamente come li hai inviati al momento della creazione, sotto queste due chiavi.
* `props`: i `custom_properties` forniti al momento della creazione. Ogni chiave è indirizzabile nelle condizioni delle regole come `custom_values.<key>`.

### Rimedio

Quando una regola attiva `AWAITING_USER`, Didit crea la sessione di verifica collegata e la restituisce in due campi:

* `remediation`: la sessione collegata: `{ "session_id", "session_token", "url", "status" }`. Resta popolato per tutta la durata della transazione, così puoi sempre vedere come si è conclusa l'azione dell'utente.
* `action_required`: l'azione che l'utente deve compiere ora, oppure `null` quando non c'è nulla in sospeso: `{ "type": "verification_session", "url", "session_id", "session_token", "status" }`. Reindirizza l'utente a `url`, oppure passa `session_token` a un SDK di Didit. Le azioni relative all'assetto proprietario del wallet della Travel Rule usano `{ "type": "wallet_ownership", "url", "widget_session_id", "expires_at" }` e hanno la precedenza quando potrebbero applicarsi entrambe. Quando un'azione relativa all'assetto proprietario del wallet è in sospeso e la controparte del trasferimento non è stata trovata, lo stesso blocco contiene anche `reason` e `next_actions` (vedi [individuazione della controparte](https://docs.didit.me/it/transaction-monitoring/travel-rule.md#scoperta-della-controparte)).

Gli stessi due campi sono presenti nei payload dei webhook `transaction.created` e `transaction.status.updated` (`action_required`): vedi [webhook](https://docs.didit.me/it/transaction-monitoring/webhooks.md).

### Dettaglio dei costi

`null` finché non viene eseguita una funzionalità fatturabile per la transazione. Altrimenti `{ "total_price", "items": [ { "usage_type", "price", "details" } ] }`, con un elemento per ogni funzionalità a consumo (screening, arricchimento e così via).

## Conversione di valuta

`preferred_currency_amount` è `amount` convertito nella valuta preferita della tua applicazione, ai tassi di cambio medi di mercato, a meno che tu non abbia fornito `amount_in_default_currency`; in tal caso viene usato così com'è quel valore già convertito. Le condizioni delle regole su `amount` confrontano l'importo nella valuta originale; usa `preferred_currency_amount` nelle condizioni quando ti serve un'unica soglia valida per valute diverse.

## Prossimi passi

> [card] [Invia transazioni](https://docs.didit.me/it/transaction-monitoring/transactions.md)
>
> Schema completo della richiesta.

> [card] [Stati](https://docs.didit.me/it/transaction-monitoring/statuses.md)
>
> Il significato di ciascuno stato.

> [card] [Punteggio di rischio](https://docs.didit.me/it/transaction-monitoring/risk-scoring.md)
>
> Come viene calcolato il punteggio.


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