Saltar para o conteúdo principal
Gestão de casos é o centro de investigação da Didit Console. Qualquer resultado positivo AML, verificação sinalizada ou transação suspeita pode tornar-se um caso com que a sua equipa de conformidade trabalha desde a abertura até à resolução, com um registo de auditoria completo.

Ciclo de vida

Um caso passa por exatamente três estados: Para resolver um caso é necessário indicar uma resolução: Cada caso tem também uma prioridade (Low, Medium, High, por omissão Medium) e uma data limite opcional, que determina a ordenação por SLA e os sinalizadores de atraso.
Não existem os estados Under review, On hold ou Pending approval, nem gravidade Critical ou um eixo de tipo de caso. O ciclo de vida está deliberadamente fixo para que a análise, os SLA e as permissões sejam inequívocos em todos os casos, independentemente da forma como foram criados.

Um sujeito por caso

Cada caso está associado a exatamente um utilizador ou a uma empresa. Não é possível misturar sujeitos num mesmo caso, nem associar a um caso uma sessão, uma sessão empresarial ou uma transação que pertença a um sujeito diferente do caso; nesse caso, é devolvido um erro claro. Isto mantém cada página de caso focada: o cartão do sujeito, a visão geral de risco, os documentos e os dados financeiros descrevem todos a mesma pessoa ou empresa que o caso investiga. Para analisar uma segunda entidade, abra (ou crie) um caso separado.

Contexto de origem do Fraud Check

Ao criar um caso a partir de uma sessão do Fraud Check, são preservados o seu ID de verificação, o ID do pedido e a secção que o revisor abriu. O cartão de origem também regista o estado do analista da sessão no momento da criação do caso. A decisão do caso e a decisão da origem continuam separadas. Os clientes de API podem fornecer source_context com check_id, request_id e source_section ao criar um caso. Inclua esse pedido como uma entrada session em links. A verificação e a sessão associada devem pertencer à aplicação selecionada e uma à outra. A API lê o estado do analista por si própria e rejeita os campos de estado, recomendação ou tipo de origem fornecidos pelo cliente neste contexto.

Listas

A Gestão de casos mantém Casos, Visão geral e Atribuição disponíveis na navegação superior. O espaço de trabalho de Casos disponibiliza as vistas por estado Abertos, A aguardar utilizador, Resolvidos e Todos. Ao abrir um caso, a fila de casos fica ao lado dos respetivos detalhes no computador. Em dispositivos móveis, use a navegação em migalhas para voltar à fila. A pesquisa corresponde ao nome ou ID do sujeito, à tag, ao número do caso, ao título do caso, ao ID da sessão associada e ao ID da transação associada. Assim, pode colar um UUID de sessão ou de transação e chegar diretamente ao respetivo caso. Chips de filtro: Modelo, Criada, Origem, Atribuído e Etiqueta, além de Adicionar filtro para Prioridade e Prazo. Colunas: Criada (data e criador), Detalhes do caso (título), Estado, Modelo, Sujeito (nome e ID), Tags do sujeito, Atribuído, Prioridade e Data limite. Há mais colunas disponíveis através de deslocamento horizontal e da configuração de colunas.

Ordenação e SLA

Ordene por Criado em (predefinido) ou Data limite. Ordenar por data limite mostra primeiro os casos em atraso. Um caso está em atraso assim que a sua data limite tiver passado enquanto continuar Aberto ou a aguardar utilizador, e é assinalado com um chip vermelho de prazo.

Vistas guardadas

Guarde a combinação atual de filtros e colunas como uma vista com nome através de Guardar vista, alterne entre vistas com Selecionar uma vista e reponha com Limpar filtros. As vistas são pessoais e são guardadas da mesma forma que as outras preferências de tabelas da consola.

Ações em massa

Selecione vários casos para:
  • Atribuir a um responsável. Todos os casos selecionados têm de partilhar o mesmo modelo; a consola avisa antes de submeter se não partilharem.
  • Definir estado para A aguardar utilizador, Reabrir ou Resolver (com uma resolução e uma nota opcional). Cada caso é avaliado de forma independente. Assim, um caso bloqueado por uma lista de verificação incompleta ou por uma nota obrigatória em falta é comunicado individualmente, sem fazer falhar o restante lote.

Exportações

O menu da lista oferece duas exportações em CSV, entregues através da página de Relatórios:
  • Relatório de todos os casos, com uma linha por caso, com estado, resolução, prioridade, tags, transações associadas e o último relatório FIU apresentado.
  • Relatório de SLA, com métricas de tempo por caso: horas até à atribuição, horas até à resolução e indicadores de atraso e de SLA cumprido.

Ações sobre o sujeito e novas tentativas

O cartão do sujeito permite que os revisores autorizados alterem o estado do sujeito, adicionem tags, acrescentem uma nota interna ou adicionem o sujeito à lista de bloqueio. Estas ações são separadas da resolução do caso. A secção Ações sobre o sujeito regista cada ação pedida como Aplicada ou Falhada e identifica o seu revisor e a hora. Use Repetir ação para repetir uma ação falhada depois de rever o sujeito atual. Uma ação aplicada não é executada de novo quando o seu pedido é repetido. Os clientes de API devem enviar um client_reference único com cada pedido ao endpoint entity-actions/ do caso. Mantenha a mesma referência e os mesmos dados ao repetir um pedido após um erro de ligação. Dados alterados com a mesma referência devolvem 409. Quando for fornecida uma referência, verifique receipt.status: uma resposta 200 pode conter um recibo falhado, o que significa que a ação não foi aplicada. Repetir um pedido falhado exige retry: true ou uma chamada ao endpoint action-receipts/{receipt_uuid}/retry/. O endpoint de histórico devolve no máximo 20 recibos por página e fornece next_offset para obter resultados adicionais. Os clientes de API existentes que omitem client_reference mantêm o comportamento de resposta anterior.

Tags

Adicione tags a um caso a partir do respetivo cabeçalho (Adicionar tag) para agrupar investigações relacionadas, ou filtre e pesquise por tag na lista. As alterações às tags ficam registadas na cronologia do caso.

Páginas relacionadas

Criar casos

Todos os pontos de entrada: utilizadores, empresas, sessões, transações e conectores automáticos.

Blueprints

Configure a atribuição, a escalada, a transferência e o conteúdo da página do caso.

Lista de verificação

Condicione a resolução aos passos obrigatórios da investigação.

Revisão pelo princípio dos quatro olhos

Aprovação pelo criador e pelo revisor para resoluções sensíveis.

Mensagens ao cliente

Use Enviar mensagem para pré-visualizar um pedido predefinido ou uma atualização de revisão para um contacto verificado. Veja Mensagens ao cliente para os estados de entrega, as respostas seguras e o fluxo da API.

Discussão e notas fixadas

Abra o botão de discussão junto ao estado do caso para rever as notas sem interromper a investigação. Use o menu de uma nota para responder ou fixá-la. As notas fixadas aparecem primeiro, e as respostas mostram um excerto curto da nota original. As alterações de fixação são registadas na atividade do caso e não alteram as decisões de origem. Ao confirmar a eliminação, a nota e o respetivo excerto citado nas respostas são removidos permanentemente. As próprias respostas continuam disponíveis. Os anexos são eliminados, a menos que outra nota ainda os utilize. Os clientes da API podem indicar um UUID em client_reference ao adicionar uma nota. Uma nova tentativa sem alterações devolve a nota existente, sem duplicar notificações. Reutilizar essa referência para conteúdo alterado ou para uma nota eliminada devolve 409. Indique reply_to para referenciar uma nota ativa do mesmo caso, e atualize is_pinned através do endpoint PATCH da nota.

Verificar se já existe uma investigação

O diálogo partilhado Criar caso verifica se existem investigações para o utilizador, a empresa ou a origem associada selecionados. Abra um caso existente para continuar a sua análise. Os casos fechados continuam visíveis, para que possa abri-los e decidir se os reabre. Para criar uma investigação separada, indique o motivo para tratar o caso como um incidente diferente. O motivo fica guardado com o novo caso e é apresentado na respetiva visão geral. A consola volta a verificar duplicados ao submeter, incluindo casos criados por outro revisor enquanto o diálogo estava aberto. As integrações de API podem consultar POST .../cases/duplicates/ e definir review_duplicates=true na criação do caso. Quando é encontrada uma investigação existente, a criação devolve 409, a menos que seja indicado separate_incident_reason. O endpoint de revisão de duplicados devolve até 20 casos por página, com next_offset para mais resultados. As integrações de API existentes que omitem a opção mantêm o comportamento atual de criação.
Última modificação em 7 de novembro de 2026