# Contas duplicadas e busca facial

Source: https://help.didit.me/pt-BR/verification-sessions/duplicate-detection
Updated: 2026-10-12

Toda prova de vida roda uma busca facial 1:N contra quem você já verificou e contra a sua blocklist. O mesmo rosto pode ser fraude ou um cliente recorrente.

Toda verificação de prova de vida roda automaticamente uma busca facial 1:N contra os usuários
já verificados por você e contra a sua blocklist. Um sinalizador de duplicidade significa que
o mesmo rosto já apareceu antes - o que é fraude quando se trata de uma conta nova e
completamente normal quando se trata de um cliente recorrente. Diferencie os dois casos com
`vendor_data`.

## O que roda automaticamente

[Video: Busca facial e blocklists - Didit Academy](https://www.youtube.com/watch?v=7htTWCWsl60&t=413)

[Video: Listas de bloqueio, listas de permissão e listas personalizadas: pare a fraude recorrente - Didit Academy](https://www.youtube.com/watch?v=xqsJihVTbEM)

[Video: Detecção de contas duplicadas: mesmo rosto, mesmo ID, mesmo dispositivo - Didit Academy](https://www.youtube.com/watch?v=ras0mkfhvKo)

![A blocklist no console da Didit, filtrada por rostos, documentos, telefones e e-mails](https://help.didit.me/screenshots/blocklist-light.webp)

*Uma duplicidade confirmada pode ser bloqueada por rosto, documento, telefone ou e-mail.*

Quando alguém completa uma verificação de prova de vida, a Didit compara o rosto dessa pessoa com **todos os usuários já verificados na sua organização** e com a **sua blocklist**, sem que você precise ativar nada separadamente:

- Uma correspondência com um usuário já verificado gera um sinalizador de possível duplicidade na sessão.
- Uma correspondência com um rosto na blocklist reprova a verificação.

A sensibilidade é definida pelos limiares de similaridade que você configura, e o que acontece diante de uma correspondência - reprovar, revisar, ou passar com um sinalizador - é definido pelas regras do seu workflow.

## Duplicidade não é a mesma coisa que fraude

Essa é a distinção que importa, e a plataforma não pode fazer isso por você: um rosto duplicado significa *esse rosto já se verificou aqui antes*. Se isso é um problema depende inteiramente do seu produto.

| Situação | O sinalizador de duplicidade é... |
|---|---|
| Uma pessoa abrindo uma segunda conta para abusar de um bônus de cadastro | O sinal que você queria |
| Um cliente legítimo se verificando de novo depois que o KYC dele expirou | Esperado e inofensivo |
| Um cliente que abandonou e começou de novo | Esperado e inofensivo |
| Um dispositivo compartilhado em uma família ou uma loja | Precisa de uma análise humana |

## Impedindo que usuários recorrentes legítimos sejam sinalizados

A solução é informar à Didit que as duas sessões são da mesma pessoa, o que você faz com **`vendor_data`**.

Defina `vendor_data` como o seu próprio ID interno de usuário ao criar uma sessão. Sessões que compartilham o mesmo `vendor_data` são agrupadas em um único usuário consolidado, então um cliente recorrente é lido como a mesma pessoa, em vez de um desconhecido usando um rosto familiar.

> **Tip:** Se você está vendo sinalizadores de duplicidade nos seus próprios clientes recorrentes genuínos,
> verifique se a sua integração está enviando `vendor_data`. Sessões criadas
> sem esse campo não podem ser vinculadas, então toda reverificação parece um estranho que
> por acaso tem o mesmo rosto.

Para a reverificação deliberada de um usuário conhecido, a **autenticação biométrica** é o módulo feito especificamente para isso: ele reconfirma um usuário recorrente pelo rosto, sem refazer todo o fluxo de documento.

## Revisando uma duplicidade sinalizada

O resultado da sessão traz a referência para a sessão anterior que deu a correspondência, então você pode abrir as duas e comparar lado a lado - mesmo nome, mesmo número de documento, nome diferente no mesmo rosto, e assim por diante. Essa comparação é o que te diz em qual das situações acima você está.

Se for abuso genuíno, adicione o rosto à sua blocklist para que a próxima tentativa seja reprovada automaticamente. Se for o seu próprio cliente recorrente, aprove a sessão e corrija a lacuna de `vendor_data` para que isso pare de acontecer.

## Apagar dados afeta a detecção futura de duplicidade

A detecção de duplicidade funciona comparando com dados que você ainda mantém. Se você apagar uma sessão, essa sessão deixa de existir - então o rosto que ela continha não está mais lá para servir de comparação, e uma tentativa posterior da mesma pessoa não será reconhecida como duplicidade dela.

A aplicação pode reter um modelo facial sem imagem por um número definido de dias após excluir a sessão, apenas para detectar duplicatas. O diálogo mostra a configuração e permite alterá-la para essa exclusão. Um pedido de exclusão por privacidade remove imediatamente todos os modelos da pessoa. Os modelos retidos aparecem em **Listas → Modelos biométricos**.

Essa é a troca honesta entre minimização de dados e detecção de fraude, e vale a pena decidir isso de forma deliberada em vez de descobrir depois. Veja [apagando dados de verificação](https://help.didit.me/pt-BR/data-privacy/delete-verification-data).

## Buscando um rosto você mesmo

Além da checagem automática, a busca facial está disponível como uma API para você buscar um rosto específico entre os seus usuários verificados sob demanda - útil para investigar um padrão de fraude depois do fato, em vez de no momento do onboarding. Veja [busca facial](https://docs.didit.me/standalone-apis/face-search).

## Sinais de dispositivo e IP são uma camada separada

Um rosto duplicado é um sinal; uma impressão digital de dispositivo compartilhado ou um IP suspeito é outro. São verificações independentes, e um golpista determinado geralmente vai disparar uma antes da outra. A análise de dispositivo e IP é barata (US$ 0,03 por verificação), então é uma adição barata a um fluxo que já roda prova de vida.

> **Warning:** Sinais de dispositivo e IP geram falsos positivos em infraestrutura compartilhada - redes
> corporativas, NAT de operadoras móveis, e navegadores hospedados na nuvem colocam muitos
> usuários legítimos atrás de um único endereço. Encaminhe esses casos para revisão em vez de
> reprovar apenas com base neles.