> ## 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. # Conferma proprietà wallet API Travel Rule: beneficiario > Con Didit conferma o rifiuta che il cliente controlla il wallet beneficiario di un trasferimento Travel Rule in UNCONFIRMED_OWNERSHIP. Prompt API per la conferma della proprietà del wallet Copia il prompt negli appunti \

\`Confirm or deny wallet ownership on a Travel Rule transfer waiting on the beneficiary side - typically the beneficiary leg of an INTERNAL-rail transfer whose wallet address book entry has not been ownership-verified yet, a transfer whose counterparty wallet was declared self-hosted (counterparty.payment_method.method_type: "unhosted_wallet"), an inbound transfer in ON_HOLD, or an inbound TRP inquiry a compliance officer resolves by hand.

Endpoint:
POST https://verification.didit.me/v3/transactions/{transaction_id}/travel-rule/ownership/

Authentication:
Use the x-api-key header with my Didit API key. {transaction_id} is the Didit transaction uuid of the transfer your own application holds: on an INTERNAL-rail transfer that is your (beneficiary) side; on a declared self-hosted wallet it is the transaction you created, outbound or inbound.

Request body:
\{"confirmed": true}   or   {"confirmed": false}
Optionally {"confirmed": true, "wallet_address": "0x..."} - the payment address to return to the counterparty on an inbound TRP transfer.
On a declared self-hosted wallet transfer with no counterparty wallet on it, "wallet_address" supplies the wallet to verify; if neither the transfer nor the request names one, the request is rejected with 400.

Accepted states (anything else -> 409 "Transfer is not awaiting ownership confirmation."):
\- UNCONFIRMED_OWNERSHIP, in either direction.
\- ON_HOLD on an inbound transfer.
\- UNCONFIRMED_OWNERSHIP, ON_HOLD or COUNTERPARTY_MISMATCHED_DATA on an inbound TRP transfer.

Behavior on a transfer Didit created itself (INTERNAL rail, sunrise registration, declared self-hosted wallet):
\- confirmed: true - marks the matching wallet address book entry ownership-verified, then runs the beneficiary name match on both sides: COMPLETED on a pass, COUNTERPARTY_MISMATCHED_DATA on a fail.
An inbound transfer whose deposit already settled then moves on to FINISHED.
\- confirmed: true on a declared self-hosted wallet - records that the customer verified who controls the counterparty wallet and completes the transfer (COMPLETED), outbound or inbound; an inbound deposit whose on-chain hash is already known moves on to FINISHED. The wallet is the counterparty's: the destination of a withdrawal, the originator's source wallet of a deposit. If it is not in the wallet address book yet, it is added as ownership-verified under the counterparty's name; if the book already holds it under a different holder name, the transfer goes to COUNTERPARTY_MISMATCHED_DATA.
\- confirmed: false - moves both sides of the transfer to COUNTERPARTY_VASP_GENERAL_DECLINE.
\- Resolving an inbound ON_HOLD with no matching entry, or confirming a declared self-hosted wallet, creates the entry from the transfer's wallet address and marks it verified.

Behavior on an inbound TRP transfer (answering the counterparty's inquiry):
\- confirmed: true - needs a payment address, taken from the request's wallet_address, then the matched entry, then beneficiary_data.wallet_address.
Didit creates or verifies the entry, posts the inquiry-resolution callback to the counterparty, sets ownership_confirmed and moves the transfer to COMPLETED.
\- confirmed: false - posts a declined resolution and moves the transfer to COUNTERPARTY_VASP_GENERAL_DECLINE.

Transfers a network delivered (GTR or Sygna Bridge):
\- An inbound transfer that waits for your review (UNCONFIRMED_OWNERSHIP, ON_HOLD or COUNTERPARTY_MISMATCHED_DATA) is decided here: confirmed: true approves it (send wallet_address when the transfer names none), confirmed: false declines it. Didit answers the network after the response, with retries; the response's delivery field shows that answer.
\- VerifyVASP takes its answer when it asks, so a VerifyVASP transfer that would need your review is declined at once and cannot be decided here.
\- Receiving over a network is switched on by Didit per network, and none is switched on today.

What to read from the response:
\- The full transfer object. originator_data/beneficiary_data stay masked on inbound transfers (data_masked: true) until ownership is confirmed; data_unmasked then records when, why and by whom. data_match and mismatched_fields name the fields that differ after a mismatch.

Alternative: instead of this API call, send the end customer through the hosted wallet-ownership widget (POST /v3/travel-rule/widget-session/) and let them prove control cryptographically.

Failure modes:
\- 400 - on an inbound TRP approval with no payment address available: {"wallet_address": ["wallet_address is required to approve."]}.
\- 409 - the transfer is not in one of the accepted states, no entry in your wallet address book matches the transfer's wallet address (an inbound TRP approval, and an inbound ON_HOLD transfer that carries beneficiary_data.wallet_address, and a declared self-hosted wallet, create the missing entry instead), an INTERNAL transfer from another Didit customer needs a control proof (signed message or test deposit) first, or a network transfer was already answered over its network (a VerifyVASP transfer, or a GTR or Sygna Bridge transfer already decided).
\- 502 - the counterparty's TRP inquiry-resolution callback could not be delivered; the transfer keeps its current status.
\- 404 - unknown transaction or no Travel Rule transfer attached.

Full guide: /transaction-monitoring/travel-rule#confirming-wallet-ownership.`

\
Incolla in ## Wallet in autocustodiaQuando il wallet della controparte è stato dichiarato in autocustodia (`counterparty.payment_method.method_type: "unhosted_wallet"`), la transazione resta in `UNCONFIRMED_OWNERSHIP`. Chiamando questo endpoint con `confirmed: true` si registra che il tuo cliente ha verificato chi controlla quel wallet, e la transazione viene completata (`COMPLETED`), sia per i prelievi in uscita sia per i depositi in entrata. Un deposito in entrata il cui hash on-chain è già noto passa a `FINISHED`.Il wallet verificato è quello della controparte: la destinazione di un prelievo in uscita oppure la sorgente (il wallet dell'ordinante) di un deposito in entrata. Didit lo aggiunge alla rubrica degli indirizzi come wallet di cui è stata verificata la proprietà, a nome della controparte, quindi viene confrontato con il nome della controparte (dell'ordinante, nel caso di un deposito). Se nella rubrica degli indirizzi quel wallet è già associato a un nome del titolare diverso, la transazione passa invece a `COUNTERPARTY_MISMATCHED_DATA`.Se la transazione non indica alcun wallet della controparte, passa `wallet_address` nel corpo della richiesta. Quando né la transazione né la richiesta forniscono un indirizzo di wallet, la richiesta viene rifiutata con `400`.`confirmed: false` rifiuta la transazione (`COUNTERPARTY_VASP_GENERAL_DECLINE`). ## OpenAPI ````yaml it/openapi-25.json POST /v3/transactions/{transaction_id}/travel-rule/ownership/ openapi: 3.0.0 info: version: 3.0.0 title: Didit Verification API description: API di verifica dell'identità. Autenticati con l'intestazione x-api-key. servers: - url: https://verification.didit.me security: [] tags: [] paths: /v3/transactions/{transaction_id}/travel-rule/ownership/: post: tags: - Travel Rule summary: Conferma o nega l'assetto proprietario del wallet description: >- Risolvi un trasferimento in attesa dell'assetto proprietario del wallet: chiamalo dal tuo lato del trasferimento quando è UNCONFIRMED_OWNERSHIP, oppure quando è un trasferimento in entrata in ON_HOLD. La conferma contrassegna la voce corrispondente nella rubrica degli indirizzi wallet come verificata per la proprietà (per un trasferimento in entrata ON_HOLD senza alcuna voce, Didit ne crea una da beneficiary_data.wallet_address) ed esegue la corrispondenza del nome del beneficiario su entrambi i lati del trasferimento; il diniego rifiuta entrambi i lati. Un trasferimento in entrata il cui deposito è già stato regolato passa a FINISHED quando la corrispondenza ha successo. Quando il wallet della controparte è stato dichiarato in autocustodia (counterparty.payment_method.method_type: unhosted_wallet), la conferma registra che il cliente ha verificato chi controlla tale wallet e completa il trasferimento (COMPLETED) in entrambe le direzioni, o FINISHED per un deposito in entrata il cui hash on-chain è già noto. Il wallet verificato è quello della controparte: la destinazione di un prelievo in uscita o l'origine (il wallet dell'ordinante) di un deposito in entrata. Se non è ancora presente nella tua rubrica degli indirizzi wallet, Didit lo aggiunge come verificato per la proprietà con il nome della controparte; se la rubrica lo contiene già con un nome di titolare diverso, il trasferimento passa a COUNTERPARTY_MISMATCHED_DATA. Per un trasferimento TRP in entrata in UNCONFIRMED_OWNERSHIP, ON_HOLD o COUNTERPARTY_MISMATCHED_DATA, Didit invia invece la tua decisione al VASP ordinante: l'approvazione restituisce l'indirizzo di pagamento (wallet_address o l'indirizzo della voce corrispondente) e sposta il trasferimento a COMPLETED, mentre il diniego lo rifiuta. La stessa chiamata decide anche un trasferimento in entrata inviato da una controparte GTR o Sygna Bridge e in attesa della tua revisione (`UNCONFIRMED_OWNERSHIP`, `ON_HOLD` o `COUNTERPARTY_MISMATCHED_DATA`): `confirmed: true` lo approva (passa `wallet_address` quando il trasferimento non ne indica alcuno) e `confirmed: false` lo rifiuta, e la rete riceve la risposta successivamente, con nuovi tentativi. VerifyVASP riceve la risposta al momento della richiesta, pertanto un trasferimento VerifyVASP che richiederebbe la tua revisione viene rifiutato immediatamente e non può essere deciso in seguito. operationId: confirmTravelRuleOwnership parameters: - name: transaction_id in: path required: true description: >- UUID stabile di Didit della transazione che la tua applicazione detiene per questo trasferimento: la transazione lato beneficiario su un trasferimento su circuito INTERNAL, o la transazione che hai creato (in entrata o in uscita) quando il wallet della controparte è stato dichiarato in autocustodia. schema: type: string format: uuid requestBody: required: true content: application/json: schema: $ref: '#/components/schemas/TravelRuleOwnershipConfirmRequest' example: confirmed: true responses: '200': description: >- Il trasferimento aggiornato. Per un trasferimento in entrata, i dati originator_data/beneficiary_data della controparte rimangono mascherati (`data_masked: true`) finché la titolarità non viene confermata; successivamente `data_unmasked` registra quando, perché e da chi. content: application/json: schema: $ref: '#/components/schemas/TravelRuleTransferDetail' '400': description: >- Errore di validazione: confirmed è mancante, un'approvazione TRP in entrata non ha alcun wallet_address e nessun indirizzo su cui ripiegare, oppure `confirmed: true` su un trasferimento dichiarato verso un wallet in autocustodia che non specifica alcun wallet della controparte e non è stato inviato alcun `wallet_address`. content: application/json: examples: No payment address: value: wallet_address: - wallet_address is required to approve. '404': description: >- Transazione sconosciuta, oppure la transazione non contiene alcun trasferimento Travel Rule. '409': description: >- Il trasferimento non è in attesa di conferma dell'assetto proprietario, nessuna voce della rubrica degli indirizzi wallet corrisponde al relativo wallet della controparte, un trasferimento INTERNAL da un altro cliente Didit richiede una prova di controllo (un messaggio firmato o un deposito di prova) prima di poter essere confermato, oppure un trasferimento di rete ha già ricevuto risposta sulla relativa rete (un trasferimento VerifyVASP, o un trasferimento GTR o Sygna Bridge su cui tu o Didit avete già deciso). content: application/json: examples: Not awaiting confirmation: value: detail: Transfer is not awaiting ownership confirmation. No matching address book entry: value: detail: wallet address entry no longer available '502': description: >- Solo per trasferimenti TRP in entrata: Didit non è riuscito a recapitare la tua decisione al VASP ordinante, pertanto lo stato del trasferimento non cambia. content: application/json: examples: Callback not delivered: value: detail: >- Counterparty inquiry-resolution callback could not be delivered. security: - ApiKeyAuth: [] x-codeSamples: - lang: curl label: curl source: >- curl -X POST https://verification.didit.me/v3/transactions/{transaction_id}/travel-rule/ownership/ \ -H 'x-api-key: YOUR_API_KEY' -H 'Content-Type: application/json' \ -d '{"confirmed": true}' - lang: python label: Python source: |- from didit import Didit # Reads DIDIT_API_KEY. client = Didit() result = client.transactions.travel_rule.confirm_ownership( "11111111-2222-3333-4444-555555555555", confirmed=True, ) print(result) - lang: javascript label: Node.js source: >- import Didit from "@didit-protocol/sdk-node"; // Reads DIDIT_API_KEY. const didit = new Didit(); const result = await didit.transactions.travelRule.confirmOwnership("11111111-2222-3333-4444-555555555555", { confirmed: true, }); console.log(result); - lang: go label: Go source: "ctx := context.Background()\n// Reads DIDIT_API_KEY.\nclient := didit.NewClient()\n\nresult, err := client.Transactions.TravelRule.ConfirmOwnership(ctx, \"11111111-2222-3333-4444-555555555555\", didit.TravelRuleOwnershipConfirmRequest{\n\tConfirmed: true,\n})\nif err != nil {\n\tlog.Fatal(err)\n}\nfmt.Printf(\"%+v\\n\", result)" - lang: java label: Java source: >- import me.didit.Didit; import me.didit.types.TravelRuleOwnershipConfirmRequest; // Reads DIDIT_API_KEY. Didit client = new Didit(); var result = client.transactions().travelRule().confirmOwnership("11111111-2222-3333-4444-555555555555", TravelRuleOwnershipConfirmRequest.builder() .confirmed(true) .build()); System.out.println(result); - lang: php label: PHP source: >- transactions->travelRule->confirmOwnership('11111111-2222-3333-4444-555555555555', [ 'confirmed' => true, ]); print_r($result->toArray()); - lang: ruby label: Ruby source: |- require "didit" # Reads DIDIT_API_KEY. didit = Didit::Client.new result = didit.transactions.travel_rule.confirm_ownership( "11111111-2222-3333-4444-555555555555", confirmed: true ) puts result.to_h - lang: csharp label: .NET source: >- using System; using System.Text.Json; using Didit; // Reads DIDIT_API_KEY. using var client = new DiditClient(); var result = await client.Transactions.TravelRule.ConfirmOwnershipAsync("11111111-2222-3333-4444-555555555555", new TravelRuleOwnershipConfirmRequest { Confirmed = true, }); Console.WriteLine(JsonSerializer.Serialize(result)); components: schemas: TravelRuleOwnershipConfirmRequest: type: object required: - confirmed properties: confirmed: type: boolean description: true per confermare l'assetto proprietario, false per negarlo. wallet_address: type: string default: '' description: >- Trasferimenti TRP in entrata: l'indirizzo di pagamento restituito da Didit al VASP ordinante al momento dell'approvazione. Il valore predefinito corrisponde all'indirizzo della voce della rubrica corrispondente, quindi a beneficiary_data.wallet_address. Nel caso di un trasferimento dichiarato verso un wallet in autocustodia che non specifica un wallet di controparte, il wallet di cui hai verificato l'assetto proprietario; in sua assenza la richiesta viene rifiutata con 400. Ignorato per altri trasferimenti. TravelRuleTransferDetail: type: object description: >- Oggetto di trasferimento completo restituito dagli endpoint di conferma della titolarità e di completamento/annullamento. Finché la titolarità del wallet di un trasferimento in entrata non è confermata, i campi `originator_data` e `beneficiary_data` della controparte vengono restituiti mascherati (viene mantenuta la prima lettera di ogni parola; il wallet, la chain e l'instradamento VASP rimangono leggibili) e `data_masked` è true. properties: uuid: type: string format: uuid status: type: string enum: - AWAITING_COUNTERPARTY - ON_HOLD - COMPLETED - FINISHED - CANCELLED - EXPIRED - COUNTERPARTY_MISMATCHED_DATA - COUNTERPARTY_VASP_NOT_FOUND - COUNTERPARTY_VASP_NOT_REACHABLE - UNCONFIRMED_OWNERSHIP - COUNTERPARTY_VASP_GENERAL_DECLINE - NOT_ENOUGH_COUNTERPARTY_DATA - NOT_APPLICABLE direction: type: string enum: - INBOUND - OUTBOUND rail: type: string nullable: true enum: - INTERNAL - TRP - GTR - TRUST - VERIFYVASP - SYGNA - EMAIL - TEST_VASP - null description: >- Il canale (rail) su cui è stato instradato il trasferimento, o null quando non è stato selezionato alcun canale (ad esempio sotto la soglia, un wallet della controparte in autocustodia, una registrazione post-deposito o nessuna controparte raggiungibile). INTERNAL indica che entrambe le parti sono applicazioni Didit; EMAIL indica che la controparte è stata raggiunta tramite un link di ritiro inviato via email. TEST_VASP indica che il Didit Test VASP ha risposto al trasferimento sandbox. Tramite GTR, VERIFYVASP e SYGNA, Didit legge la risposta della controparte dalla risposta della rete o effettuando un polling ogni 5 minuti. TRUST invia soltanto, quindi un trasferimento TRUST rimane AWAITING_COUNTERPARTY fino alla scadenza. Un canale di rete viene utilizzato solo dopo aver collegato la propria iscrizione per tale rete. Viene scelto dopo che la creazione della transazione ha restituito risposta, quindi è null in tale risposta. protocol: type: string nullable: true ivms_version: type: string example: ivms101.2023 required: type: boolean ownership_confirmed: type: boolean nullable: true deadline_at: type: string format: date-time nullable: true timeline: type: array items: type: object properties: status: type: string at: type: string format: date-time detail: type: string name_match: allOf: - $ref: '#/components/schemas/TravelRuleNameMatch' nullable: true description: >- Il confronto dei nomi che ha determinato questa voce, accanto a `detail`. Assente nelle voci che non hanno confrontato alcun nome. reason: type: string description: >- Presente solo sulla voce di una transizione causata da una mancata consegna: `email_undeliverable` o `delivery_failed`, il valore riportato da `reason` del trasferimento. counterparty_vasp: type: object nullable: true properties: name: type: string lei: type: string dd_score: type: integer description: >- Punteggio di due diligence da 0 a 100, dove un valore più alto è migliore. Stessa scala utilizzata nella directory dei VASP. dd_score_breakdown: type: object description: >- Contributi per componente a dd_score, un oggetto per componente come nella directory VASP (giurisdizione, verifica, protocollo, lei, cronologia, elementi essenziali, reattività), ciascuno con {points, max, reason, detail}. {} finché la controparte non è stata valutata. additionalProperties: type: object properties: points: type: number description: Punti assegnati per questo componente. max: type: integer description: Punti massimi che questo componente può assegnare. reason: type: string description: Codice leggibile dalla macchina dell'esito del componente. detail: type: string description: Motivo leggibile dall'utente per i punti assegnati. dd_assessed_at: type: string format: date-time nullable: true description: >- Data e ora dell'ultima esecuzione della valutazione di adeguata verifica. Null finché la controparte non è stata valutata. originator_data: type: object description: >- Soggetto ordinante. Per un trasferimento in entrata, i valori della controparte sono oscurati fino alla conferma dell'assetto proprietario. beneficiary_data: type: object description: >- Parte beneficiaria. Per un trasferimento in entrata i valori della controparte sono mascherati fino a quando non viene confermato l'assetto proprietario. name_match: allOf: - $ref: '#/components/schemas/TravelRuleNameMatch' nullable: true description: >- Il confronto dei nomi che ha determinato il trasferimento, o null fino all'esecuzione. Mentre le parti sono oscurate, e sulla copia dell'altro cliente di uno scambio INTERNAL, `transfer_name`, `compared_name`, `matched_names` e `mismatched_names` rimangono nascosti. `score` e `matched` possono discordare: `matched` segue il livello di rigore, `score` è la somiglianza dei due nomi completi. data_match: $ref: '#/components/schemas/TravelRuleDataMatch' mismatched_fields: type: array items: type: string description: >- Scorciatoia per `data_match.mismatched_fields`. Vuoto quando non ci sono differenze. data_unmasked: $ref: '#/components/schemas/TravelRuleDataUnmasked' data_masked: type: boolean description: >- True mentre i dati personali della controparte sono mascherati in questa risposta. created_at: type: string format: date-time delivery: nullable: true allOf: - $ref: '#/components/schemas/TravelRuleDelivery' description: >- Lo stato dell'ultimo messaggio dovuto da questo trasferimento alla controparte. Null quando il trasferimento non ha mai dovuto inviarne uno (ad esempio al di sotto di `threshold_amount`, un wallet in autocustodia dichiarato o una registrazione sunrise). discovery: type: array description: >- Modalità con cui Didit ha cercato la controparte, una voce per ogni passaggio eseguito. Vuoto se non è stata eseguita alcuna ricerca, ad esempio per un trasferimento in entrata. items: $ref: '#/components/schemas/TravelRuleDiscoveryStep' reason: type: string description: >- Il motivo per cui un trasferimento `COUNTERPARTY_VASP_NOT_FOUND` o `COUNTERPARTY_VASP_NOT_REACHABLE` è bloccato; `""` per qualsiasi altro stato. Una consegna non riuscita lo determina per prima, solo su `COUNTERPARTY_VASP_NOT_REACHABLE`: `email_undeliverable` (il provider di posta ha rifiutato l'email di compliance e non è rimasto alcun indirizzo da provare: quando è stata inviata, in un promemoria o come bounce permanente segnalato successivamente) o `delivery_failed` (il canale che effettuava la consegna è fallito definitivamente: un canale di rete ha rifiutato il messaggio o ha esaurito i tentativi, un host di identità `TRP` non ha risposto o l'host `TRP` della controparte non ha accettato la richiesta). Altrimenti lo determina la traccia di `discovery`: `awaiting_end_user` (nessun passaggio ha indicato una controparte raggiungibile da Didit), `directory_match_no_route` (un passaggio ha indicato un VASP della directory privo di rotta), `picked_member_without_proven_wallet` (l'utente finale ha scelto un cliente Didit che non ha dimostrato il controllo del wallet) o `no_directory_match` quando la traccia non fornisce altri motivi. Un nuovo invio fa avanzare il trasferimento, quindi il motivo viene azzerato. Consulta [Perché un trasferimento è bloccato](/it/transaction-monitoring/travel-rule#perché-un-trasferimento-è-bloccato). next_actions: type: array description: >- Cosa fa procedere il trasferimento; `[]` per qualsiasi stato tranne `COUNTERPARTY_VASP_NOT_FOUND` o `COUNTERPARTY_VASP_NOT_REACHABLE`. `email_undeliverable` propone `update_compliance_email`, poi `resend`. `delivery_failed` propone `resend`. Un motivo di discovery propone `select_counterparty_vasp`, `declare_self_hosted`, `add_vasp_hint` e `resend`. items: $ref: '#/components/schemas/TravelRuleNextAction' chain_details: $ref: '#/components/schemas/TravelRuleChainDetails' TravelRuleNameMatch: type: object nullable: true description: >- Il confronto dei nomi che ha determinato il trasferimento, o null fino all'esecuzione. Mentre le parti sono oscurate, e sulla copia dell'altro cliente di uno scambio INTERNAL, `transfer_name`, `compared_name`, `matched_names` e `mismatched_names` rimangono nascosti. `score` e `matched` possono discordare: `matched` segue il livello di rigore, `score` è la somiglianza dei due nomi completi. properties: score: type: integer minimum: 0 maximum: 100 description: >- Somiglianza dei due nomi completi, da 0 a 100. 0 quando uno dei due nomi è vuoto. matched: type: boolean description: >- Indica se i nomi soddisfano `strictness`. L'esito del trasferimento segue `data_match`, che confronta ogni campo, pertanto un trasferimento può essere COUNTERPARTY_MISMATCHED_DATA anche quando questo valore è true. method: type: string enum: - none - exact_token - token_subset - token_containment - sequence_ratio description: >- Modalità con cui è stato determinato `matched`: nessuno (`NONE`), exact_token (`STRICT`), token_subset (`DEFAULT`), token_containment (`CONTAINS`) o sequence_ratio (`FUZZY`). strictness: type: string enum: - NONE - STRICT - CONTAINS - DEFAULT - FUZZY compared_with: type: string enum: - wallet_holder - counterparty_vasp description: >- wallet_holder: il titolare registrato per il wallet. counterparty_vasp: il nome indicato dalla controparte nella pagina di risposta via email, o la risposta di Didit Test VASP in sandbox. transfer_name: type: string description: Il nome sul trasferimento. compared_name: type: string description: Il nome con cui è stato confrontato. matched_names: type: array items: type: string description: Parole di `transfer_name` trovate in `compared_name`. mismatched_names: type: array items: type: string description: >- Parole di `transfer_name` mancanti da `compared_name`, seguite dalle parole di `compared_name` mancanti da `transfer_name`. TravelRuleDataMatch: type: object nullable: true description: >- Confronto campo per campo tra i dati della parte del trasferimento e ciò che l'altra parte sa sul titolare del wallet. Riporta i nomi dei campi e i risultati, mai i valori, in modo che rimanga leggibile mentre i dati della controparte sono oscurati. Null finché non viene eseguito un confronto. properties: matched: type: boolean description: True quando nessun campo confrontato differisce. mismatched_fields: type: array items: type: string enum: - name - date_of_birth - address - account description: I campi che differiscono. fields: type: object description: >- Una voce per ciascun campo confrontato per il tipo di entità della parte (`name`, `date_of_birth`, `address`, `account`; un'azienda non ha `date_of_birth`). additionalProperties: type: object properties: result: type: string enum: - matched - mismatched - not_compared description: >- `not_compared` quando la regola è `NONE` o una delle due parti non ha un valore per il campo. strictness: type: string enum: - NONE - STRICT - CONTAINS - DEFAULT - FUZZY TravelRuleDataUnmasked: type: object nullable: true description: >- Registro di audit del momento in cui i dati della controparte sono stati smascherati. Null finché i dati sono ancora mascherati e per i trasferimenti in uscita. properties: at: type: string format: date-time reason: type: string enum: - ownership_confirmed - wallet_proof - address_book_match - own_verified_wallet - inquiry_approved - known_payment_method - travel_address description: >- Cosa ha confermato l'assetto proprietario: ownership_confirmed (la tua conferma tramite la console o l'API), wallet_proof (una prova del wallet nel widget o un trasferimento in entrata INTERNAL, impostato al momento della creazione), address_book_match (un wallet verificato nella rubrica), own_verified_wallet (il wallet verificato del tuo utente), inquiry_approved (la tua approvazione di una richiesta TRP in entrata o di un messaggio GTR o Sygna), known_payment_method (un wallet con cui il tuo utente ha già pagato) o travel_address (il Travel Address associato al wallet ha denominato il wallet). actor: type: string description: >- Chi l'ha confermata: l'email dell'utente della console o l'etichetta della chiave API. Vuoto per una decisione automatica. TravelRuleDelivery: type: object description: >- Lo stato dell'ultimo messaggio dovuto dal trasferimento alla controparte. Didit contatta la controparte dopo la restituzione della richiesta che ha creato o modificato il trasferimento, quindi questo oggetto indica se tale messaggio è andato a buon fine: in coda, in fase di invio, in attesa di un nuovo tentativo dopo un errore, consegnato o non riuscito. In caso di errore da cui la rete può ancora riprendersi (nessuna risposta in tempo, connessione non riuscita, HTTP `408`, `429` o `5xx`), viene effettuato un nuovo tentativo dopo 30 secondi, 2 minuti, 10 minuti, 30 minuti e 1 ora. Quando un primo messaggio (`kind: SEND`) fallisce definitivamente, perché la rete lo ha rifiutato o anche il sesto tentativo non è riuscito, il trasferimento passa a `COUNTERPARTY_VASP_NOT_REACHABLE` con `last_error` nella sua `timeline`; qualsiasi altro messaggio che fallisce definitivamente viene annotato nella `timeline`. Lo `status` del trasferimento rimane l'unica fonte di verità per lo scambio stesso. required: - kind - status - rail - attempts - last_error - next_attempt_at - delivered_at properties: kind: type: string enum: - SEND - ANSWER - TXID - CANCEL - POLL description: >- Cosa trasporta il messaggio. `SEND`: il primo messaggio del trasferimento verso la controparte (in uscita; il canale viene scelto al momento dell'invio). `ANSWER`: la tua accettazione o rifiuto, dovuta alla rete che ha effettuato la richiesta (in entrata). `TXID`: l'hash della transazione on-chain, dopo aver completato il trasferimento. `CANCEL`: l'annullamento, dopo averlo cancellato. `POLL`: una richiesta di stato verso una rete che la supporta, ripetuta ogni 5 minuti mentre il trasferimento è in attesa della controparte. status: type: string enum: - QUEUED - SENDING - RETRYING - DELIVERED - FAILED description: >- `QUEUED`: in attesa di invio. `SENDING`: tentativo in corso. `RETRYING`: un tentativo non è riuscito e il prossimo verrà eseguito alle `next_attempt_at`. `DELIVERED`: l'altra parte ha ricevuto il messaggio. `FAILED`: l'altra parte lo ha rifiutato o l'ultimo tentativo non è riuscito. rail: type: string enum: - INTERNAL - TRP - GTR - TRUST - VERIFYVASP - SYGNA - EMAIL - '' description: >- Il canale (rail) che trasporta il messaggio. Vuoto finché Didit non ne sceglie uno per un primo messaggio. attempts: type: integer minimum: 0 description: >- Tentativi effettuati finora per questo messaggio. Per un messaggio che non è un polling di stato vengono effettuati al massimo 6 tentativi. last_error: type: string description: >- Il tipo di errore riscontrato nell'ultimo tentativo, `""` se non ce ne sono stati: ad esempio `email undeliverable`, `trp identity endpoint unreachable` o `trp transfer inquiry delivery failed`. Non contiene mai la risposta della controparte stessa, che rimane nella `timeline` del trasferimento. Quando GTR risponde con un errore, vengono inclusi il codice di stato e il messaggio restituiti. I corpi della risposta non vengono mai inclusi. example: email undeliverable next_attempt_at: type: string format: date-time nullable: true description: >- Quando verrà eseguito il prossimo tentativo mentre il messaggio è in stato `QUEUED` o `RETRYING`. delivered_at: type: string format: date-time nullable: true description: Quando l'altra parte ha preso in carico il messaggio. TravelRuleDiscoveryStep: type: object description: >- Un passaggio del rilevamento della controparte eseguito da Didit per un trasferimento in uscita, nell'ordine in cui è stato eseguito. Il primo passaggio che identifica un VASP con un percorso conclude la catena. properties: step: type: string enum: - internal_address_book - wallet_attribution - network_lookup - customer_hint - end_user description: >- `internal_address_book`: un altro cliente Didit che ha dimostrato il controllo del wallet di destinazione. `wallet_attribution`: l'attribuzione di analisi blockchain del wallet. `network_lookup`: una rete in grado di indicare quale VASP detiene l'indirizzo. `customer_hint`: il nome del VASP, LEI o la giurisdizione che hai inviato in `beneficiary_data`. `end_user`: la controparte scelta dall'utente finale (o da te), oppure la richiesta di sceglierne una. outcome: type: string enum: - match - miss - skipped description: >- `match`: il passaggio ha indicato una controparte. `miss`: è stato eseguito e non ne ha trovata nessuna. `skipped`: non è stato possibile eseguirlo e `reason` ne indica il motivo. reason: type: string description: >- Motivo leggibile dalla macchina, `""` in caso di corrispondenza: `no_proven_internal_wallet`, `attribution_disabled`, `already_attributed`, `no_attributed_entity`, `directory_match_no_route`, `gtr_address_lookup_runs_on_dispatch`, `no_membership`, `network_switched_off`, `no_network_address_lookup`, `no_directory_match`, `awaiting_end_user` o `picked_member_without_proven_wallet`. vasp: type: string format: uuid nullable: true description: >- Il VASP della directory indicato dal passaggio, qualora ne abbia indicato uno. rail: type: string nullable: true description: >- Il canale (rail) che raggiunge tale controparte, quando il passaggio ne ha trovato uno. at: type: string format: date-time TravelRuleNextAction: type: object description: >- Un elemento che consente di far progredire un trasferimento bloccato nello stato `COUNTERPARTY_VASP_NOT_FOUND` o `COUNTERPARTY_VASP_NOT_REACHABLE`. Consulta [Perché un trasferimento è bloccato](/it/transaction-monitoring/travel-rule#perché-un-trasferimento-è-bloccato). properties: action: type: string enum: - select_counterparty_vasp - declare_self_hosted - add_vasp_hint - update_compliance_email - resend description: >- `select_counterparty_vasp`: l'utente finale seleziona il VASP di destinazione nel widget di titolarità del wallet, oppure invii una richiesta PATCH con `action=beneficiary_vasp`. `declare_self_hosted`: l'utente finale dichiara che il wallet è in autocustodia nel widget. `add_vasp_hint`: indica a Didit chi è la controparte specificando nome del VASP, LEI o Travel Address (ad esempio un `travel_address` nella voce della rubrica del wallet di destinazione), quindi invia nuovamente. `update_compliance_email` e `resend` sono valori di `action` per `PATCH /v3/transactions/{transaction_id}/travel-rule/`: fornisci nuovamente l'email di compliance della controparte ed esegui nuovamente l'instradamento. url: type: string format: uri description: >- Il link al widget di verifica della proprietà del wallet, su `select_counterparty_vasp` e `declare_self_hosted` mentre il trasferimento ha una sessione widget aperta. required: - action TravelRuleChainDetails: type: object description: >- In che modo la blockchain del trasferimento identifica i suoi due wallet, quando si tratta di più di un indirizzo che ne paga un altro. Vuoto (`{}`) per un trasferimento su blockchain basata su account (EVM, Solana, Tron), dove i due indirizzi corrispondono ai wallet. La corrispondenza, l'instradamento e la rubrica leggono innanzitutto i wallet da qui. properties: chain: type: string description: >- Rete blockchain canonica, ad es. `BTC`, `XRP` o `LIGHTNING` per un trasferimento Lightning. shape: type: string enum: - utxo - memo - lightning originator: $ref: '#/components/schemas/TravelRuleChainSide' beneficiary: $ref: '#/components/schemas/TravelRuleChainSide' utxo: type: object description: >- Su un trasferimento UTXO: gli input e gli output come memorizzati (importi come stringhe decimali) e quali output Didit ha interpretato come cosa. properties: inputs: type: array items: $ref: '#/components/schemas/TravelRuleUtxoEntry' outputs: type: array items: $ref: '#/components/schemas/TravelRuleUtxoEntry' change_output_indexes: type: array items: type: integer description: Output che rimborsano un indirizzo di input. beneficiary_output_index: type: integer nullable: true description: >- L'output che paga il beneficiario; null quando non è stato possibile distinguerne alcuno. lightning: type: object description: >- Su un trasferimento Lightning: ciò che indica la richiesta di pagamento. Sempre `kind` (`bolt11`, `bolt12_offer`, `bolt12_invoice`, `bolt12_invoice_request`, `lnurl`, `lightning_address`, `node_id` o `unknown`); una fattura BOLT11 aggiunge `network`, `payee_node_id`, `payment_hash`, `amount_msat`, `created_at` e `expires_at`; una stringa BOLT12 `blinded_paths` e `payee_node_id`; un LNURL o un Lightning Address il suo `domain`. Nulla viene risolto sulla rete: la richiesta viene solo decodificata. additionalProperties: true warnings: type: array items: type: string enum: - declared_originator_not_an_input - declared_beneficiary_not_an_output - beneficiary_output_ambiguous - beneficiary_output_amount_differs description: >- Incongruenze UTXO da esaminare: l'ordinante dichiarato non è un input, il beneficiario dichiarato non è un output, non è stato possibile distinguere un singolo output del beneficiario, oppure l'output del beneficiario corrisponde a un importo diverso rispetto a quello indicato nella transazione. not_applicable_reason: type: string enum: - LIGHTNING_NO_PAYEE_IDENTIFIER - LIGHTNING_BOLT12_BLINDED_PAYEE - LIGHTNING_LNURL_NAMES_NO_PAYEE description: >- Su un trasferimento Lightning in uscita la cui richiesta di pagamento non indica alcun beneficiario: perché il trasferimento è `NOT_APPLICABLE`. `LIGHTNING_NO_PAYEE_IDENTIFIER` (la richiesta non indica alcun nodo beneficiario o non è stato possibile decodificarla), `LIGHTNING_BOLT12_BLINDED_PAYEE` (l'offerta nasconde il proprio beneficiario dietro percorsi ciechi), `LIGHTNING_LNURL_NAMES_NO_PAYEE` (un LNURL indica un servizio, non un beneficiario). Lo stesso codice apre l'ultima voce `timeline` del trasferimento. TravelRuleChainSide: type: object description: >- Il wallet di una delle parti, così come Didit lo ha risolto a partire dai dati della blockchain. properties: address: type: string description: >- Il wallet. Su una rete con memo l'indirizzo classico (un X-address XRP viene suddiviso nel relativo indirizzo classico e tag); su Lightning l'ID del nodo del beneficiario o il Lightning Address. memo: type: string description: Il destination tag o memo che fa parte del wallet; `""` se assente. source: type: string enum: - declared - x_address - largest_input - only_non_change_output - amount_match - invoice_payee - updated description: >- Origine del wallet: `declared` (la tua richiesta), `x_address` (estratto da un X-address XRP), `largest_input` (l'indirizzo di input UTXO che ha contribuito maggiormente), `only_non_change_output` (l'unico output UTXO non di resto), `amount_match` (l'unico output UTXO che paga l'importo del trasferimento), `invoice_payee` (il beneficiario indicato in una richiesta di pagamento Lightning), `updated` (impostato successivamente con `action: update_originator_wallet`). TravelRuleUtxoEntry: type: object description: >- Un input o output di una transazione UTXO, così come registrato dalla blockchain. required: - address properties: address: type: string maxLength: 128 amount: type: string nullable: true description: >- Stringa decimale nell'unità propria della moneta (BTC, non satoshi). Facoltativo. example: '0.0125' txid: type: string maxLength: 128 description: Opzionale. La transazione utilizzata da un input. vout: type: integer nullable: true minimum: 0 description: Opzionale. L'indice di output speso da un input. securitySchemes: ApiKeyAuth: type: apiKey in: header name: x-api-key description: >- La chiave API della tua applicazione, da Developers -> API keys nella Business Console. La chiave primaria ha accesso completo. Una chiave con nome può avere un ambito definito: nessuno, lettura o scrittura per risorsa, limitata ad alcuni workflow o a sessioni approvate, a un elenco di indirizzi IP e a una data di scadenza. 401 indica che la chiave è errata, revocata o scaduta; 403 indica che non è stata inviata alcuna chiave, che la chiave non ha accesso a questa risorsa o azione, oppure che la richiesta proviene da un indirizzo non incluso nel suo elenco IP; 404 su una route di sessione indica che la sessione non rientra nei workflow o negli stati previsti dalla chiave. Una chiave senza accesso ai media riceve gli URL di immagini, video e PDF come null, e una chiave senza permessi di scrittura sulle sessioni riceve link e token di sessione come null. Consulta https://docs.didit.me/console/api-keys. ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.