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
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.
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.
#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.
#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.
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.
Ainda com dúvida? Fale com uma pessoa.
Inclua o ID da sua organização e o ID da sessão sobre a qual você está perguntando.
