> ## 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. # Estados KYT: Transação e Caso > Referência de todos os estados de transação, caso e Travel Rule, com transições. Didit: 1,000 transações/mês incluídas, depois $0.001 cada. O Transaction Monitoring tem três máquinas de estados separadas: a **transação**, cada **caso** e (quando aplicável) a **verificação da Travel Rule**. Esta página é a referência. ## Estado da transação Definido na criação e atualizado ao longo do ciclo de vida. | Estado | Significado | | - | - | | `APPROVED` | A transação passou em todas as regras abaixo do limiar de análise. | | `IN_REVIEW` | A pontuação ultrapassou o limiar de análise, ou uma regra exigiu expressamente análise. É necessária a atenção de um analista. | | `DECLINED` | A pontuação ultrapassou o limiar de recusa, ou uma regra recusou expressamente. A transação foi rejeitada. | | `AWAITING_USER` | O utilizador tem de agir antes de a transação poder ser liquidada. A Didit define este estado apenas através de uma regra: a ação `change_status` de uma regra (por exemplo, a regra da biblioteca ativada por opção `travel-rule-pending-action`, que é acionada numa transferência Travel Rule em `ON_HOLD`), ou uma ação de regra que exigiu verificação adicional (foi criada uma sessão de remediação). Uma transferência Travel Rule que precise de prova de controlo da carteira não define este estado por si só: a transação mantém o estado que as suas regras lhe atribuem (normalmente `APPROVED`) e o bloco `action_required` contém o URL de propriedade da carteira sempre que houver uma sessão do widget pendente. Leia o bloco `action_required` da transação para conhecer a ação concreta e o URL. | ### Transições ```mermaid theme={null} stateDiagram-v2 [*] --> APPROVED: Score < review threshold, no blocking rules [*] --> IN_REVIEW: Score >= review threshold [*] --> DECLINED: Score >= decline threshold, or rule decline action [*] --> AWAITING_USER: Rule action change_status → AWAITING_USER IN_REVIEW --> APPROVED: Analyst cleared IN_REVIEW --> DECLINED: Analyst declined AWAITING_USER --> APPROVED: Remediation session approved AWAITING_USER --> DECLINED: Remediation session declined AWAITING_USER --> IN_REVIEW: Remediation session ended in review ``` Nota: fora da Travel Rule, não existe nenhuma transição direta de `APPROVED` ou `DECLINED` para outros estados. Em caso de expiração da Travel Rule, o seu `timeout_outcome` define `IN_REVIEW` (`HOLD`) ou `DECLINED` (`REJECT`), seja qual for o estado atual, e uma regra que seja acionada após uma transição da Travel Rule pode alterar uma transação `APPROVED`. Para correções, use as atualizações de estado através da consola; estas ficam registadas no registo de auditoria. ## Alertas Não existe um estado de alerta separado. Um alerta aberto é uma transação em `IN_REVIEW` ou `AWAITING_USER`, por isso use o estado da transação indicado acima. Consulte [Alertas](https://docs.didit.me/pt/transaction-monitoring/alerts.md). ## Estado do caso Consulte [Gestão de casos](https://docs.didit.me/pt/console/case-management/cases.md) para ver o detalhe completo. | Estado | Significado | | - | - | | `OPEN` | Em investigação ativa. | | `AWAITING_USER` | A aguardar informação do lado do utilizador. | | `RESOLVED` | Encerrado com uma resolução: `FALSE_POSITIVE`, `VALID_THREAT`, `INCONCLUSIVE`, `REQUIREMENTS_NOT_MET` ou `REQUIREMENTS_SATISFIED`. | Os casos têm uma **prioridade** separada (`LOW`, `MEDIUM`, `HIGH`). ## Estado da verificação da Travel Rule As transferências de ativos virtuais ao abrigo da Travel Rule do GAFI executam uma **troca de 13 estados** dedicada, separada do estado da transação acima. Uma transferência de saída começa em `AWAITING_COUNTERPARTY`, `NOT_APPLICABLE` (abaixo de `threshold_amount`), `UNCONFIRMED_OWNERSHIP` (carteira da contraparte declarada como autocustodiada), `COMPLETED` ou `COUNTERPARTY_MISMATCHED_DATA` (uma correspondência `INTERNAL` numa carteira verificada, consoante a correspondência do nome), `COUNTERPARTY_VASP_NOT_FOUND` ou `COUNTERPARTY_VASP_NOT_REACHABLE`. Uma transferência de entrada pode também começar em `ON_HOLD` ou `NOT_ENOUGH_COUNTERPARTY_DATA`, e um registo sunrise que corresponda a uma carteira verificada, com um nome do beneficiário correspondente ou ausente, passa diretamente por `COMPLETED` até `FINISHED`. A troca termina em `FINISHED`, `CANCELLED` ou `EXPIRED`. | Estado | Significado | | - | - | | `AWAITING_COUNTERPARTY` | Enviado à contraparte; a aguardar a resposta. Uma transferência enviada através da TRUST permanece neste estado até expirar, porque a TRUST não devolve nada que a Didit possa ler. Numa aplicação de sandbox, a transferência é encaminhada para o [VASP de teste da Didit](https://docs.didit.me/pt/transaction-monitoring/travel-rule-sandbox.md), que responde dentro da Didit com o cenário que escolher. | | `UNCONFIRMED_OWNERSHIP` | A propriedade da carteira do beneficiário ainda não foi comprovada. | | `ON_HOLD` | A Didit define este estado apenas em transferências de entrada: um registo sunrise ou um pedido `TRP` de entrada cuja carteira não está no seu livro de endereços (ou, para um pedido apenas com o nome, cujo nome não corresponde a um único titular verificado), ou um pedido `TRP` de entrada que exige a sua decisão manual (a aceitação automática está desativada, ou não foi possível entregar a resposta automática). Não altera o estado da transação por si só; a regra da biblioteca ativada por opção `travel-rule-pending-action` define `AWAITING_USER`. Resolva-o com `POST /v3/transactions/{id}/travel-rule/ownership/`. | | `COMPLETED` | Os dados do ordenante e do beneficiário correspondem - pode ser transmitido na blockchain em segurança. | | `FINISHED` | Hash on-chain comunicado; a troca está encerrada. | | `CANCELLED` | Cancelado a partir de um estado não terminal. | | `EXPIRED` | Prazo de confirmação expirado. Apenas uma transferência que ainda esteja em `AWAITING_COUNTERPARTY` no seu prazo expira, verificada de 15 em 15 minutos; os restantes estados nunca expiram. O seu `timeout_outcome` é aplicado à transação, e essa alteração não envia nenhum webhook `transaction.status.updated`. | | `COUNTERPARTY_MISMATCHED_DATA` | O nome do beneficiário não correspondeu. | | `COUNTERPARTY_VASP_NOT_FOUND` | Nenhuma rede conseguiu identificar a contraparte. | | `COUNTERPARTY_VASP_NOT_REACHABLE` | A contraparte foi identificada, mas a Didit não conseguiu entregar a mensagem: o endpoint `TRP` estava inacessível ou comunicou um LEI diferente ou em falta, ou um nome diferente, ou uma rede (GTR, TRUST, VerifyVASP, Sygna Bridge) não conseguiu entregar a mensagem. | | `COUNTERPARTY_VASP_GENERAL_DECLINE` | A contraparte recusou a troca. | | `NOT_ENOUGH_COUNTERPARTY_DATA` | Um pedido `TRP` de entrada não identificou o beneficiário nem pelo nome nem pelo endereço da carteira. Não tem prazo, e o endpoint de propriedade não o consegue resolver; por isso, cancele-o com `action: "cancel"`. O remetente não é notificado. A Didit nunca define este estado numa transferência de saída; surge aí apenas quando o regista manualmente, e pode repetir essa transferência com `action: "resend"`. | | `NOT_APPLICABLE` | Abaixo de `threshold_amount`, por isso nada foi trocado, ou um valor que registou numa transferência que a Didit não executa (Travel Rule desativada, uma transação cujo tipo não é `travelRule`, ou um valor legado). | As integrações mais antigas podem ainda enviar os valores legados `UNKNOWN`, `COMPLIANT`, `PENDING_ACTION`, `PENDING_COUNTERPARTY`, `FAILED` e `EXEMPT`; a Didit associa-os automaticamente aos estados acima. Consulte [Travel Rule](https://docs.didit.me/pt/transaction-monitoring/travel-rule.md#ciclo-de-vida) para a referência autorizada. ## Estado do resultado do fornecedor Cada resultado de fornecedor externo (triagem de carteiras, monitorização fiat, triagem de sanções) é guardado com o seu próprio estado. É apresentado em `provider_results[]` na resposta da transação. | Estado | Significado | | - | - | | `PENDING` | Consulta ao fornecedor em curso. | | `COMPLETED` | Resultado devolvido com êxito. | | `FAILED` | O fornecedor devolveu um erro ou excedeu o tempo limite. | | `SKIPPED` | Fornecedor ignorado intencionalmente (por exemplo, transação abaixo do limiar). | ## Resultados das execuções de regras Cada `TransactionRuleRun` tem: * `matched` (booleano): a regra foi acionada? * `is_test` (booleano): a regra estava em modo TEST? * `mode`: `ACTIVE`, `DISABLED` ou `TEST` no momento da avaliação. * `score_delta`: contributo para a pontuação (se acionada e ativa). * `status_target`: o estado solicitado pela regra (se for uma ação `change_status`). Consulte [Regras](https://docs.didit.me/pt/transaction-monitoring/rules.md) para a anatomia da regra. ## Códigos de motivo da decisão Valores `reason` comuns nas transições de estado: | Motivo | Significado | | - | - | | `rule_score_threshold` | A pontuação ultrapassou o limiar de análise ou recusa. | | `rule_change_status` | A ação `change_status` de uma regra forçou um estado. | | `analyst_approved` / `analyst_declined` / `analyst_cleared` | Ação manual do analista. | | `user_action_approved` / `user_action_declined` / `user_action_in_review` | Resultado da sessão de correção associada (a ação do utilizador solicitada enquanto `AWAITING_USER`). | | `provider_update` | O fornecedor externo atualizou o resultado. | | `aml_confirmed_sanction` | A triagem AML confirmou uma correspondência em sanções. | | `blocklist_applicant` / `blocklist_counterparty` | Aplicação da lista de bloqueio a uma parte. | ## Próximos passos > [card] [Pontuação de risco](https://docs.didit.me/pt/transaction-monitoring/risk-scoring.md) > > Como as pontuações são mapeadas para estados. > [card] [Alertas](https://docs.didit.me/pt/transaction-monitoring/alerts.md) > > Ciclo de vida dos alertas. > [card] [Casos](https://docs.didit.me/pt/transaction-monitoring/cases.md) > > Ciclo de vida dos casos. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.