Pular para o conteúdo principal
Gerenciamento de casos é o centro de investigação do Didit Console. Cada alerta de AML, verificação sinalizada ou transação suspeita pode virar um caso que sua equipe de conformidade conduz da abertura à resolução, com um registro de auditoria completo.

Ciclo de vida

Um caso passa por exatamente três status: Para resolver um caso, é obrigatório informar uma resolução: Todo caso também tem uma prioridade (Low, Medium, High, padrão Medium) e uma data de vencimento opcional, que define a ordenação por SLA e as sinalizações de atraso.
Não existe status Under review, On hold ou Pending approval, nem severidade Critical ou classificação por tipo de caso. O ciclo de vida é fixo de propósito, para que análises, SLAs e permissões sejam inequívocos em todos os casos, independentemente de como cada um foi criado.

Uma entidade por caso

Todo caso está vinculado a exatamente um usuário ou uma empresa. Não é possível misturar entidades em um mesmo caso, nem anexar uma sessão, sessão de empresa ou transação que pertença a um entidade diferente da do caso: isso retorna um erro claro. Assim, cada página de caso permanece focada: o card da entidade, a visão geral de risco, os documentos e os dados financeiros descrevem a mesma pessoa ou empresa investigada no caso. Para analisar uma segunda entidade, abra (ou crie) um caso separado.

Contexto de origem do Fraud Check

Criar um caso a partir de uma sessão do Fraud Check preserva o ID da verificação, o ID da requisição e a seção que o revisor abriu. O cartão de origem também registra o status do analista na sessão no momento da criação do caso. A decisão do caso e a decisão da origem permanecem separadas. Clientes da API podem enviar source_context com check_id, request_id e source_section ao criar um caso. Inclua essa requisição como uma entrada session em links. A verificação e a sessão vinculada devem pertencer à aplicação selecionada e uma à outra. A própria API lê o status do analista e rejeita campos de status, recomendação ou tipo de origem enviados pelo chamador nesse 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 Casos oferece as visualizações de status Aberto, Aguardando usuário, Resolvidos e Todos. No desktop, ao abrir um caso, a fila de casos continua visível ao lado dos detalhes. No celular, use a trilha de navegação para voltar à fila. A busca encontra correspondências por nome ou ID do sujeito, tag, número do caso, título do caso, ID da sessão vinculada e ID da transação vinculada, então você pode colar o UUID de uma sessão ou transação e ir direto para o caso correspondente. Filtros rápidos: Modelo, Criada, Origem, Responsável, Tag, além de Adicionar filtro para Prioridade e Vencimento. Colunas: Criada (data e criador), Detalhes do caso (título), Status, Modelo, Sujeito (nome e ID), Tags do sujeito, Atribuído, Prioridade e Data de vencimento, com mais colunas disponíveis pela rolagem horizontal e pela configuração de colunas.

Ordenação e SLA

Ordene por Criado em (padrão) ou Data de vencimento. A ordenação por data de vencimento mostra primeiro os casos atrasados. Um caso fica atrasado quando a data de vencimento já passou enquanto ele ainda está Aberto ou Aguardando usuário, e isso aparece com um indicador de vencimento vermelho.

Visualizações salvas

Salve a combinação atual de filtros e colunas como uma visualização nomeada com Salvar visualização, alterne entre visualizações com Selecionar uma visualização e redefina com Limpar filtros. As visualizações são pessoais e persistem da mesma forma que as outras preferências de tabela do console.

Ações em massa

Selecione vários casos para:
  • Atribuir a um responsável. Todos os casos selecionados devem compartilhar o mesmo modelo. Se não compartilharem, o console avisa antes do envio.
  • Definir status como Aguardando usuário, Reabrir ou Resolver (com uma resolução e uma nota opcional). Cada caso é avaliado de forma independente, então um caso bloqueado por uma checklist incompleta ou pela falta de uma nota obrigatória é informado individualmente, sem fazer o restante do lote falhar.

Exportações

O menu da lista oferece duas exportações em CSV, disponibilizadas na página de Relatórios:
  • Relatório de todos os casos, com uma linha por caso contendo status, resolução, prioridade, tags, transações vinculadas e o último relatório enviado à FIU.
  • Relatório de SLA, com métricas de tempo por caso: horas até a atribuição, horas até a resolução, indicadores de atraso e de cumprimento do SLA.

Ações sobre o sujeito e novas tentativas

O cartão do sujeito permite que revisores autorizados alterem o status do sujeito, adicionem tags, adicionem uma nota interna ou incluam o sujeito na lista de bloqueio. Essas ações são separadas da resolução do caso. A seção Subject actions registra cada ação solicitada como Applied ou Failed e identifica o revisor e o horário. Use Retry action para tentar novamente uma ação que falhou, depois de revisar o sujeito atual. Uma ação aplicada não é executada de novo quando a requisição dela é repetida. Clientes da API devem enviar um client_reference único em cada requisição ao endpoint entity-actions/ do caso. Mantenha a mesma referência e os mesmos dados de entrada ao repetir uma requisição após um erro de conexão. Dados de entrada alterados com a mesma referência retorna 409. Quando uma referência for enviada, verifique receipt.status: uma resposta 200 pode conter um recibo com falha, o que significa que a ação não foi aplicada. Para tentar novamente uma requisição que falhou, é necessário retry: true ou uma chamada ao endpoint action-receipts/{receipt_uuid}/retry/ correspondente. O endpoint de histórico retorna no máximo 20 recibos por página e fornece next_offset para resultados adicionais. Clientes da API existentes que omitem client_reference mantêm o comportamento de resposta anterior.

Tags

Adicione tags a um caso pelo cabeçalho (Adicionar tag) para agrupar investigações relacionadas, ou filtre e pesquise por tag na lista. As alterações de tags ficam registradas na linha do tempo do caso.

Páginas relacionadas

Criação de casos

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

Blueprints

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

Checklist

Condicione a resolução às etapas de investigação obrigatórias.

Revisão a quatro olhos

Aprovação maker/checker para resoluções sensíveis.

Mensagens ao cliente

Use Enviar mensagem para pré-visualizar uma solicitação predefinida ou uma atualização sobre a revisão para um contato verificado. Consulte Mensagens ao cliente para ver os status de entrega, as respostas seguras e o fluxo pela API.

Discussão e notas fixadas

Abra o botão de discussão ao lado do status do caso para revisar as notas sem sair da investigação. Use o menu de uma nota para respondê-la ou fixá-la. As notas fixadas aparecem primeiro, e as respostas mostram um pequeno trecho da nota principal. As alterações de fixação ficam registradas na atividade do caso e não alteram as decisões de origem. Ao confirmar a exclusão, você remove permanentemente a nota e o trecho dela citado nas respostas. As respostas em si continuam disponíveis. Os anexos são excluídos, a menos que outra nota ainda os utilize. Os clientes de API podem informar um UUID client_reference ao adicionar uma nota. Uma nova tentativa sem alterações retorna a nota existente, sem duplicar notificações. Reutilizar essa referência com conteúdo alterado ou para uma nota excluída retorna 409. Informe reply_to para referenciar uma nota ativa do mesmo caso e atualize is_pinned pelo endpoint PATCH da nota.

Verificar se já existe uma investigação

A caixa de diálogo compartilhada do Create Case verifica se já existem investigações para o usuário, a empresa ou a origem vinculada selecionada. Abra um caso existente para continuar a revisá-lo. Os casos encerrados continuam visíveis para que você possa abri-los e decidir se deve reabri-los. Para criar uma investigação separada, informe um motivo para tratá-la como um incidente diferente. O motivo é salvo com o novo caso e exibido na visão geral dele. O console verifica novamente se há duplicatas ao enviar, incluindo casos criados por outro revisor enquanto a caixa de diálogo estava aberta. As integrações via API podem consultar POST .../cases/duplicates/ e definir review_duplicates=true na criação do caso. Quando uma investigação existente é encontrada, a criação retorna 409, a menos que separate_incident_reason seja informado. O endpoint de revisão de duplicatas retorna até 20 casos por página, com next_offset para mais resultados. As integrações via API existentes que omitem essa opção mantêm o comportamento atual de criação.
Última modificação em 1 de novembro de 2026