> ## 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. # API para confirmar propiedad de wallet: Travel Rule > Confirma o rechaza en Didit que tu cliente controla la wallet beneficiaria de una transferencia Travel Rule entrante en UNCONFIRMED_OWNERSHIP. Prompt para la API de confirmación de propiedad de wallets Copiar el prompt al portapapeles \

\`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.`

\
Pegar en ## Wallets sin custodiaCuando la wallet de la contraparte se declaró sin custodia (`counterparty.payment_method.method_type: "unhosted_wallet"`), la transferencia queda en espera en `UNCONFIRMED_OWNERSHIP`. Llamar a este endpoint con `confirmed: true` registra que tu cliente verificó quién controla esa wallet y completa la transferencia (`COMPLETED`), tanto en retiros salientes como en depósitos entrantes. Un depósito entrante cuyo hash on-chain ya se conoce pasa a `FINISHED`.La wallet verificada es la de la contraparte: el destino de un retiro saliente, o el origen (la wallet del ordenante) de un depósito entrante. Didit la añade a la libreta de direcciones de wallets como wallet con propiedad verificada a nombre de la contraparte, de modo que se compara con el nombre de la contraparte (el ordenante, en el caso de un depósito). Si la libreta de direcciones ya contiene esa wallet con un nombre de titular diferente, la transferencia pasa a `COUNTERPARTY_MISMATCHED_DATA`.Si la transferencia no indica ninguna wallet de la contraparte, envía `wallet_address` en el cuerpo de la solicitud. Cuando ni la transferencia ni la solicitud aportan una dirección de wallet, la solicitud se rechaza con `400`.`confirmed: false` rechaza la transferencia (`COUNTERPARTY_VASP_GENERAL_DECLINE`). ## OpenAPI ````yaml es/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 de verificación de identidad. Autentícate con el encabezado x-api-key. servers: - url: https://verification.didit.me security: [] tags: [] paths: /v3/transactions/{transaction_id}/travel-rule/ownership/: post: tags: - Travel Rule summary: Confirmar o negar la propiedad de la wallet description: >- Resuelve una transferencia que espera la confirmación de propiedad de la wallet: llámalo en tu propio lado de la transferencia cuando esté en UNCONFIRMED_OWNERSHIP, o cuando sea una transferencia entrante en ON_HOLD. Confirmar marca la entrada correspondiente de la libreta de direcciones de wallets como de propiedad verificada (para una transferencia entrante en ON_HOLD sin entrada, Didit crea una a partir de beneficiary_data.wallet_address) y ejecuta la comparación del nombre del beneficiario en ambos lados de la transferencia; denegar rechaza ambos lados. Una transferencia entrante cuyo depósito ya se liquidó pasa a FINISHED cuando la comparación tiene éxito. Cuando la wallet de la contraparte se declaró como wallet sin custodia (counterparty.payment_method.method_type: unhosted_wallet), confirmar registra que el cliente verificó quién controla esa wallet y completa la transferencia (COMPLETED) en ambas direcciones, o FINISHED en el caso de un depósito entrante cuyo hash on-chain ya se conoce. La wallet verificada es la de la contraparte: el destino de un retiro saliente, o el origen (la wallet del ordenante) de un depósito entrante. Si todavía no está en tu libreta de direcciones de wallets, Didit la añade como de propiedad verificada a nombre de la contraparte; si la libreta ya la tiene registrada con un nombre de titular distinto, la transferencia pasa a COUNTERPARTY_MISMATCHED_DATA. Para una transferencia TRP entrante en UNCONFIRMED_OWNERSHIP, ON_HOLD o COUNTERPARTY_MISMATCHED_DATA, Didit envía en su lugar tu decisión al VASP de origen: aprobar devuelve la dirección de pago (wallet_address, o la dirección de la entrada coincidente) y pasa la transferencia a COMPLETED, y denegar la rechaza. La misma llamada también decide una transferencia entrante que envió una contraparte de GTR o Sygna Bridge y que espera tu revisión (`UNCONFIRMED_OWNERSHIP`, `ON_HOLD` o `COUNTERPARTY_MISMATCHED_DATA`): `confirmed: true` la aprueba (pasa `wallet_address` cuando la transferencia no indica ninguna) y `confirmed: false` la rechaza, y se responde a la red después de la respuesta, con reintentos. VerifyVASP recibe su respuesta en el momento en que la solicita, por lo que una transferencia de VerifyVASP que necesitaría tu revisión se rechaza de inmediato y no se puede decidir más tarde. operationId: confirmTravelRuleOwnership parameters: - name: transaction_id in: path required: true description: >- UUID estable de Didit de la transacción que tu aplicación mantiene para esta transferencia: la transacción del lado del beneficiario en una transferencia por la vía INTERNAL, o la transacción que creaste (saliente o entrante) cuando la wallet de la contraparte se declaró como wallet sin custodia. schema: type: string format: uuid requestBody: required: true content: application/json: schema: $ref: '#/components/schemas/TravelRuleOwnershipConfirmRequest' example: confirmed: true responses: '200': description: >- La transferencia actualizada. En una transferencia entrante, los originator_data/beneficiary_data de la contraparte permanecen enmascarados (`data_masked: true`) hasta que se confirma la propiedad; después, `data_unmasked` registra cuándo, por qué y quién lo hizo. content: application/json: schema: $ref: '#/components/schemas/TravelRuleTransferDetail' '400': description: >- Error de validación: falta confirmed, una aprobación TRP entrante no tiene wallet_address ni ninguna dirección que usar en su lugar, o se envió `confirmed: true` en una transferencia declarada desde una wallet sin custodia que no indica ninguna wallet de contraparte y no se envió `wallet_address`. content: application/json: examples: No payment address: value: wallet_address: - wallet_address is required to approve. '404': description: >- Transacción desconocida, o la transacción no tiene ninguna transferencia de Travel Rule. '409': description: >- La transferencia no está a la espera de confirmación de propiedad, ninguna entrada de la libreta de direcciones de wallets coincide con su wallet de contraparte, una transferencia INTERNAL de otro cliente de Didit necesita una prueba de control (un mensaje firmado o un depósito de prueba) antes de poder confirmarse, o una transferencia de red ya se respondió a través de su red (una transferencia de VerifyVASP, o una transferencia de GTR o Sygna Bridge que tú o Didit ya decidieron). 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 para transferencias TRP entrantes: Didit no pudo entregar tu decisión al VASP ordenante, por lo que el estado de la transferencia no 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 para confirmar la propiedad, false para negarla. wallet_address: type: string default: '' description: >- Transferencias TRP entrantes: la dirección de pago que Didit devuelve al VASP ordenante cuando apruebas. De forma predeterminada es la dirección de la entrada coincidente de la libreta de direcciones y, si no la hay, beneficiary_data.wallet_address. En una transferencia declarada a una wallet sin custodia que no indica ninguna wallet de la contraparte, es la wallet cuya propiedad verificaste; sin ella, la solicitud se rechaza con 400. Se ignora en las demás transferencias. TravelRuleTransferDetail: type: object description: >- Objeto de transferencia completo que devuelven los endpoints de confirmación de propiedad y de finalizar/cancelar. Mientras la propiedad de la wallet de una transferencia entrante no esté confirmada, los `originator_data` y `beneficiary_data` de la contraparte se devuelven enmascarados (se conserva la primera letra de cada palabra; la wallet, la cadena y el enrutamiento del VASP siguen siendo legibles) y `data_masked` es 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: >- La vía por la que se enrutó la transferencia, o null cuando no se seleccionó ninguna vía (por ejemplo, por debajo del umbral, con una wallet sin custodia de la contraparte, con un registro posterior al depósito o sin una contraparte alcanzable). INTERNAL significa que ambas partes son aplicaciones de Didit; EMAIL significa que se llegó a la contraparte mediante un enlace de recogida enviado por correo electrónico. TEST_VASP significa que el VASP de prueba de Didit respondió a la transferencia del sandbox. Por GTR, VERIFYVASP y SYGNA, Didit lee la respuesta de la contraparte en la respuesta de la red o consultándola cada 5 minutos. TRUST solo envía, por lo que una transferencia por TRUST permanece en AWAITING_COUNTERPARTY hasta que expira. Una vía de red solo se usa cuando has conectado tu propia membresía a esa red. Se elige después de que la creación de la transacción responde, por lo que es null en esa respuesta. 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: >- La comparación de nombres que decidió esta entrada, junto a `detail`. No aparece en las entradas que no compararon ningún nombre. reason: type: string description: >- Presente solo en la entrada de una transición causada por una entrega fallida: `email_undeliverable` o `delivery_failed`, el valor que informa el `reason` de la transferencia. counterparty_vasp: type: object nullable: true properties: name: type: string lei: type: string dd_score: type: integer description: >- Puntuación de diligencia debida de 0 a 100, donde un valor más alto es mejor. Usa la misma escala que el directorio de VASP. dd_score_breakdown: type: object description: >- Contribuciones de cada componente a dd_score, un objeto por componente como en el directorio de VASP (jurisdiction, verification, protocol, lei, history, essentials, responsiveness), cada uno con {points, max, reason, detail}. {} hasta que se haya evaluado la contraparte. additionalProperties: type: object properties: points: type: number description: Puntos otorgados a este componente. max: type: integer description: Puntos máximos que puede otorgar este componente. reason: type: string description: Código legible por máquina del veredicto del componente. detail: type: string description: Motivo legible de los puntos asignados. dd_assessed_at: type: string format: date-time nullable: true description: >- Cuándo se ejecutó por última vez la evaluación de diligencia debida. Nulo hasta que se haya evaluado la contraparte. originator_data: type: object description: >- Parte ordenante. En una transferencia entrante, los valores de la contraparte están enmascarados hasta que se confirma la propiedad. beneficiary_data: type: object description: >- Parte beneficiaria. En una transferencia entrante, los valores de la contraparte están enmascarados hasta que se confirma la propiedad. name_match: allOf: - $ref: '#/components/schemas/TravelRuleNameMatch' nullable: true description: >- La comparación de nombres que decidió la transferencia, o null hasta que se haya ejecutado una. Mientras las partes están enmascaradas, y en la copia del otro cliente de un intercambio INTERNAL, `transfer_name`, `compared_name`, `matched_names` y `mismatched_names` se ocultan. `score` y `matched` pueden no coincidir: `matched` sigue el nivel de exigencia y `score` es la similitud entre los dos nombres completos. data_match: $ref: '#/components/schemas/TravelRuleDataMatch' mismatched_fields: type: array items: type: string description: >- Atajo para `data_match.mismatched_fields`. Vacío cuando nada difiere. data_unmasked: $ref: '#/components/schemas/TravelRuleDataUnmasked' data_masked: type: boolean description: >- True mientras los datos personales de la contraparte están enmascarados en esta respuesta. created_at: type: string format: date-time delivery: nullable: true allOf: - $ref: '#/components/schemas/TravelRuleDelivery' description: >- Estado del último mensaje que esta transferencia debe a la otra parte. Es nulo cuando la transferencia nunca debió ninguno (por ejemplo, por debajo de `threshold_amount`, una wallet sin custodia declarada o un registro de sunrise). discovery: type: array description: >- Cómo buscó Didit la contraparte, con una entrada por cada paso ejecutado. Vacío cuando no se ejecutó ningún descubrimiento, por ejemplo, en una transferencia entrante. items: $ref: '#/components/schemas/TravelRuleDiscoveryStep' reason: type: string description: >- Por qué está bloqueada una transferencia `COUNTERPARTY_VASP_NOT_FOUND` o `COUNTERPARTY_VASP_NOT_REACHABLE`; `""` para cualquier otro estado. Primero lo determina una entrega fallida, solo en `COUNTERPARTY_VASP_NOT_REACHABLE`: `email_undeliverable` (el proveedor de correo rechazó el correo de cumplimiento y no queda ninguna dirección que probar: al enviarlo, en un recordatorio o como rebote permanente notificado más tarde) o `delivery_failed` (el canal que realizaba la entrega falló de forma definitiva: un canal de red rechazó el mensaje o agotó los reintentos, un host de identidad `TRP` no respondió o el host `TRP` de la contraparte no aceptó la consulta). En caso contrario, lo determina la traza `discovery`: `awaiting_end_user` (ningún paso indicó una contraparte a la que Didit pueda llegar), `directory_match_no_route` (un paso indicó un VASP del directorio que no tiene ruta), `picked_member_without_proven_wallet` (el usuario final eligió un cliente de Didit que no ha demostrado el control de la wallet) o `no_directory_match` cuando la traza no da ningún otro motivo. Un reenvío hace avanzar la transferencia, por lo que el motivo se borra. Consulta [Por qué está bloqueada una transferencia](/es/transaction-monitoring/travel-rule#por-qué-una-transferencia-está-bloqueada). next_actions: type: array description: >- Qué hace avanzar la transferencia; `[]` para cualquier estado que no sea `COUNTERPARTY_VASP_NOT_FOUND` o `COUNTERPARTY_VASP_NOT_REACHABLE`. `email_undeliverable` ofrece `update_compliance_email` y después `resend`. `delivery_failed` ofrece `resend`. Un motivo de descubrimiento ofrece `select_counterparty_vasp`, `declare_self_hosted`, `add_vasp_hint` y `resend`. items: $ref: '#/components/schemas/TravelRuleNextAction' chain_details: $ref: '#/components/schemas/TravelRuleChainDetails' TravelRuleNameMatch: type: object nullable: true description: >- La comparación de nombres que decidió la transferencia, o null hasta que se haya ejecutado una. Mientras las partes están enmascaradas, y en la copia del otro cliente de un intercambio INTERNAL, `transfer_name`, `compared_name`, `matched_names` y `mismatched_names` se ocultan. `score` y `matched` pueden no coincidir: `matched` sigue el nivel de exigencia y `score` es la similitud entre los dos nombres completos. properties: score: type: integer minimum: 0 maximum: 100 description: >- Similitud de los dos nombres completos, de 0 a 100. 0 cuando alguno de los nombres está vacío. matched: type: boolean description: >- Si los nombres cumplen `strictness`. El resultado de la transferencia depende de `data_match`, que compara todos los campos, por lo que una transferencia puede ser COUNTERPARTY_MISMATCHED_DATA aunque este valor sea true. method: type: string enum: - none - exact_token - token_subset - token_containment - sequence_ratio description: >- Cómo se decidió `matched`: none (`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: el titular registrado para la wallet. counterparty_vasp: el nombre que respondió la contraparte en la página de respuesta por correo electrónico, o la respuesta del Didit Test VASP en sandbox. transfer_name: type: string description: El nombre que figura en la transferencia. compared_name: type: string description: El nombre con el que se comparó. matched_names: type: array items: type: string description: Palabras de `transfer_name` que se encuentran en `compared_name`. mismatched_names: type: array items: type: string description: >- Palabras de `transfer_name` que faltan en `compared_name` y, a continuación, palabras de `compared_name` que faltan en `transfer_name`. TravelRuleDataMatch: type: object nullable: true description: >- Comparación campo a campo de los datos de las partes de la transferencia con lo que la otra parte sabe del titular de la wallet. Indica campos y resultados, nunca valores, por lo que sigue siendo legible mientras los datos de la contraparte están enmascarados. Es null hasta que se realiza una comparación. properties: matched: type: boolean description: True cuando ningún campo comparado difiere. mismatched_fields: type: array items: type: string enum: - name - date_of_birth - address - account description: Los campos que difieren. fields: type: object description: >- Una entrada por campo comparado para el tipo de entidad de la parte (`name`, `date_of_birth`, `address`, `account`; una empresa no tiene `date_of_birth`). additionalProperties: type: object properties: result: type: string enum: - matched - mismatched - not_compared description: >- `not_compared` cuando la regla es `NONE` o alguna de las dos partes no tiene valor para el campo. strictness: type: string enum: - NONE - STRICT - CONTAINS - DEFAULT - FUZZY TravelRuleDataUnmasked: type: object nullable: true description: >- Registro de auditoría del momento en que se desenmascararon los datos de la contraparte. Es null mientras los datos siguen enmascarados, y en las transferencias salientes. 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: >- Qué confirmó la propiedad: ownership_confirmed (tu confirmación a través de la consola o de la API), wallet_proof (una prueba de wallet en el widget o una transferencia entrante INTERNAL; se establece al crearla), address_book_match (una wallet verificada de la libreta de direcciones), own_verified_wallet (la propia wallet verificada de tu usuario), inquiry_approved (tu aprobación de una consulta TRP entrante o de un mensaje GTR o Sygna), known_payment_method (una wallet con la que tu usuario ya pagó) o travel_address (la travel address propia de cada wallet identificó la wallet). actor: type: string description: >- Quién lo confirmó: el correo electrónico del usuario de la consola o la etiqueta de la clave de API. Vacío en una decisión automática. TravelRuleDelivery: type: object description: >- Estado del último mensaje que la transferencia debe a la otra parte. Didit contacta con la contraparte después de que la solicitud que creó o modificó la transferencia haya respondido, así que este objeto indica si ese mensaje llegó: en cola, en envío, a la espera de reintentarse tras un error, entregado o fallido. Un fallo del que la red aún puede recuperarse (sin respuesta a tiempo, conexión fallida, HTTP `408`, `429` o `5xx`) se reintenta a los 30 segundos, 2 minutos, 10 minutos, 30 minutos y 1 hora. Cuando un primer mensaje (`kind: SEND`) falla de forma definitiva, porque la red lo rechazó o porque también falló el sexto intento, la transferencia pasa a `COUNTERPARTY_VASP_NOT_REACHABLE` con `last_error` en su `timeline`; cualquier otro mensaje que falle de forma definitiva se registra en el `timeline`. El `status` de la transferencia sigue siendo la fuente de verdad del intercambio en sí. required: - kind - status - rail - attempts - last_error - next_attempt_at - delivered_at properties: kind: type: string enum: - SEND - ANSWER - TXID - CANCEL - POLL description: >- Qué transporta el mensaje. `SEND`: el primer mensaje de la transferencia a la contraparte (saliente; el canal se elige al enviarlo). `ANSWER`: tu aceptación o rechazo, que se debe a la red que lo solicitó (entrante). `TXID`: el hash de la transacción on-chain, después de que completes la transferencia. `CANCEL`: la cancelación, después de que la canceles. `POLL`: una consulta de estado a una red que la ofrece, repetida cada 5 minutos mientras la transferencia espera a la contraparte. status: type: string enum: - QUEUED - SENDING - RETRYING - DELIVERED - FAILED description: >- `QUEUED`: en espera de envío. `SENDING`: hay un intento en curso. `RETRYING`: un intento falló y el siguiente se ejecuta en `next_attempt_at`. `DELIVERED`: la otra parte aceptó el mensaje. `FAILED`: la otra parte lo rechazó, o falló el último intento. rail: type: string enum: - INTERNAL - TRP - GTR - TRUST - VERIFYVASP - SYGNA - EMAIL - '' description: >- La vía que transporta el mensaje. Vacía hasta que Didit elige una para un primer mensaje. attempts: type: integer minimum: 0 description: >- Intentos realizados hasta ahora para este mensaje. Un mensaje que no es una consulta de estado se intenta como máximo 6 veces. last_error: type: string description: >- El tipo de fallo que tuvo el último intento, `""` si no hubo ninguno: por ejemplo `email undeliverable`, `trp identity endpoint unreachable` o `trp transfer inquiry delivery failed`. Nunca incluye la respuesta de la propia contraparte, que permanece en el `timeline` de la transferencia. Cuando GTR responde con un error, se incluyen su propio código de estado y su mensaje. Los cuerpos de respuesta nunca se incluyen. example: email undeliverable next_attempt_at: type: string format: date-time nullable: true description: >- Fecha y hora del próximo intento mientras el mensaje está en `QUEUED` o `RETRYING`. delivered_at: type: string format: date-time nullable: true description: Fecha y hora en que el otro extremo aceptó el mensaje. TravelRuleDiscoveryStep: type: object description: >- Un paso del descubrimiento de contraparte que Didit ejecutó para una transferencia saliente, en el orden en que los ejecutó. El primer paso que identifica un VASP con una ruta finaliza la cadena. properties: step: type: string enum: - internal_address_book - wallet_attribution - network_lookup - customer_hint - end_user description: >- `internal_address_book`: otro cliente de Didit que demostró tener el control de la wallet de destino. `wallet_attribution`: la atribución de la wallet según la analítica de blockchain. `network_lookup`: una red que puede indicar qué VASP custodia la dirección. `customer_hint`: el nombre, el LEI o la jurisdicción del VASP que enviaste en `beneficiary_data`. `end_user`: la contraparte que eligió el usuario final (o tú), o la solicitud para que se elija una. outcome: type: string enum: - match - miss - skipped description: >- `match`: el paso identificó una contraparte. `miss`: se ejecutó y no encontró ninguna. `skipped`: no se pudo ejecutar, y `reason` indica el motivo. reason: type: string description: >- Motivo legible por máquina, `""` cuando hay coincidencia: `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: El VASP del directorio que indicó el paso, cuando indicó uno. rail: type: string nullable: true description: La vía que llega a esa contraparte, cuando el paso encontró una. at: type: string format: date-time TravelRuleNextAction: type: object description: >- Algo que hace avanzar una transferencia en estado `COUNTERPARTY_VASP_NOT_FOUND` o `COUNTERPARTY_VASP_NOT_REACHABLE`. Consulta [Por qué una transferencia está bloqueada](/es/transaction-monitoring/travel-rule#por-qué-una-transferencia-está-bloqueada). properties: action: type: string enum: - select_counterparty_vasp - declare_self_hosted - add_vasp_hint - update_compliance_email - resend description: >- `select_counterparty_vasp`: el usuario final elige el VASP de destino en el widget de propiedad de la wallet, o haces un PATCH con `action=beneficiary_vasp`. `declare_self_hosted`: el usuario final declara en el widget que la wallet es sin custodia. `add_vasp_hint`: indica a Didit quién es la contraparte con un nombre de VASP, un LEI o una travel address (por ejemplo, una `travel_address` en la entrada de la libreta de direcciones de la wallet de destino) y vuelve a enviarla. `update_compliance_email` y `resend` son valores de `action` de `PATCH /v3/transactions/{transaction_id}/travel-rule/`: vuelve a indicar el correo electrónico de cumplimiento de la contraparte y vuelve a ejecutar el enrutamiento. url: type: string format: uri description: >- El enlace del widget de propiedad de la wallet, en `select_counterparty_vasp` y `declare_self_hosted` mientras la transferencia tiene una sesión de widget abierta. required: - action TravelRuleChainDetails: type: object description: >- Cómo identifica la cadena de la transferencia sus dos wallets, cuando no se trata simplemente de una dirección que paga a otra. Vacío (`{}`) en una transferencia de una cadena basada en cuentas (EVM, Solana, Tron), donde las dos direcciones son las wallets. La coincidencia, el enrutamiento y la libreta de direcciones leen las wallets primero de aquí. properties: chain: type: string description: >- Cadena canónica, p. ej., `BTC`, `XRP` o `LIGHTNING` para una transferencia Lightning. shape: type: string enum: - utxo - memo - lightning originator: $ref: '#/components/schemas/TravelRuleChainSide' beneficiary: $ref: '#/components/schemas/TravelRuleChainSide' utxo: type: object description: >- En una transferencia UTXO: las entradas y salidas tal como se almacenan (importes como cadenas decimales) y cómo interpretó Didit cada salida. 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: Salidas que devuelven fondos a una dirección de entrada. beneficiary_output_index: type: integer nullable: true description: >- La salida que paga al beneficiario; null cuando no se pudo distinguir ninguna. lightning: type: object description: >- En una transferencia Lightning: lo que indica la solicitud de pago. Siempre `kind` (`bolt11`, `bolt12_offer`, `bolt12_invoice`, `bolt12_invoice_request`, `lnurl`, `lightning_address`, `node_id` o `unknown`); una factura BOLT11 añade `network`, `payee_node_id`, `payment_hash`, `amount_msat`, `created_at` y `expires_at`; una cadena BOLT12, `blinded_paths` y `payee_node_id`; una LNURL o una Lightning Address, su `domain`. No se resuelve nada a través de la red: la solicitud solo se decodifica. 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: >- Incoherencias UTXO que conviene revisar: el ordenante declarado no es una entrada, el beneficiario declarado no es una salida, no se pudo distinguir una única salida del beneficiario o la salida del beneficiario paga un importe distinto del que indica la transacción. not_applicable_reason: type: string enum: - LIGHTNING_NO_PAYEE_IDENTIFIER - LIGHTNING_BOLT12_BLINDED_PAYEE - LIGHTNING_LNURL_NAMES_NO_PAYEE description: >- En una transferencia Lightning saliente cuya solicitud de pago no indica ningún beneficiario: por qué la transferencia es `NOT_APPLICABLE`. `LIGHTNING_NO_PAYEE_IDENTIFIER` (la solicitud no indica ningún nodo beneficiario o no se pudo decodificar), `LIGHTNING_BOLT12_BLINDED_PAYEE` (la oferta oculta su beneficiario tras rutas cegadas), `LIGHTNING_LNURL_NAMES_NO_PAYEE` (una LNURL indica un servicio, no un beneficiario). El mismo código abre la última entrada del `timeline` de la transferencia. TravelRuleChainSide: type: object description: >- La wallet de una de las partes tal como Didit la resolvió a partir de los datos de la cadena. properties: address: type: string description: >- La wallet. En una red con memo, la dirección clásica (una X-address de XRP se divide en su dirección clásica y su tag); en Lightning, el ID de nodo del beneficiario o la Lightning Address. memo: type: string description: >- La etiqueta de destino o memo que forma parte de la wallet; `""` si no hay ninguno. source: type: string enum: - declared - x_address - largest_input - only_non_change_output - amount_match - invoice_payee - updated description: >- Origen de la wallet: `declared` (tu solicitud), `x_address` (extraída de una X-address de XRP), `largest_input` (la dirección de entrada UTXO que más aportó), `only_non_change_output` (la única salida UTXO que no es cambio), `amount_match` (la única salida UTXO que paga el importe de la transferencia), `invoice_payee` (el beneficiario que indica una solicitud de pago Lightning), `updated` (establecida más tarde con `action: update_originator_wallet`). TravelRuleUtxoEntry: type: object description: >- Una entrada o salida de una transacción UTXO, tal como la registró la cadena. required: - address properties: address: type: string maxLength: 128 amount: type: string nullable: true description: >- Cadena decimal en la unidad propia de la moneda (BTC, no satoshis). Opcional. example: '0.0125' txid: type: string maxLength: 128 description: Opcional. La transacción que gasta una entrada. vout: type: integer nullable: true minimum: 0 description: Opcional. El índice de la salida que gasta una entrada. securitySchemes: ApiKeyAuth: type: apiKey in: header name: x-api-key description: >- La clave de API de tu aplicación, que encontrarás en Developers -> API keys en la Business Console. La clave principal tiene acceso completo. Una clave con nombre puede tener un alcance limitado: ninguno, lectura o escritura por recurso, limitada a algunos flujos o a sesiones aprobadas, a una lista de direcciones IP y a una fecha de caducidad. 401 significa que la clave es incorrecta, se revocó o expiró; 403 significa que no se envió ninguna clave, que la clave no tiene acceso a este recurso o acción, o que la solicitud provino de una dirección fuera de su lista de IP; 404 en una ruta de sesión significa que la sesión está fuera de los flujos o estados de la clave. Una clave sin acceso a contenido multimedia recibe las URL de imágenes, videos y PDF como null, y una clave sin permiso de escritura en sesiones recibe los enlaces y tokens de sesión como null. Consulta https://docs.didit.me/console/api-keys. ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.