> ## 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. # Revisão manual de KYC: painel do revisor > Revise sessões de KYC sinalizadas no painel do console Didit: aprove, recuse ou peça reenvio com registro de auditoria e evidências. A revisão manual é uma parte essencial de qualquer fluxo de trabalho robusto de verificação de identidade e de conformidade KYC robusto. Quando o sistema automatizado sinaliza uma sessão de verificação com avisos ou inconsistências, ela passa para o status **Em Revisão** e exige que um revisor treinado tome a decisão final. Este guia apresenta o processo completo de revisão manual, incluindo como usar o recurso de **reenvio** para dar aos usuários uma segunda chance. *** ## Visão geral do painel de verificações ![Visão geral das verificações em revisão manual](https://mintcdn.com/didit-0f962782/ibesJiSLVa9jZb5z/images/console-manual-review.png?fit=max\&auto=format\&n=ibesJiSLVa9jZb5z\&q=85\&s=4f16a753968d444bf4e917c08bcbbef5) A visualização em tabela das verificações lista todas as sessões com o status atual, o tipo de documento, o país e outros detalhes importantes, tudo em um só lugar. As sessões podem ter os seguintes status: | Status | Significado | | - | - | | **Aprovado** | O usuário passou em todas as verificações de identidade | | **Recusado** | O usuário não passou em uma ou mais verificações | | **Em Revisão** | Exige sua atenção manual antes que uma decisão possa ser tomada | | **Reenviado** | Foi solicitado ao usuário que refizesse etapas específicas da verificação | > [!WARNING] > > As sessões marcadas como **Em Revisão** acionaram um ou mais sinais de aviso durante o processamento automatizado. O número total de sessões pendentes de revisão é exibido no topo do painel de verificações. *** ## Como conduzir uma revisão manual eficaz **1. Avaliação inicial** Clique em qualquer sessão para abrir a visualização detalhada da sessão: 1. **Analise todos os avisos** exibidos na visão geral da sessão. São os sinais específicos que acionaram a revisão manual (por exemplo, pontuação de prova de vida baixa, correspondência AML ou inconsistência no documento). 2. **Analise as tentativas de verificação anteriores do usuário**: clique nos vendor data do usuário para acessar o histórico de sessões e ver se ele tem sessões de verificação anteriores. 3. **Analise a linha do tempo de eventos da sessão**: a seção de eventos traz um registro cronológico de cada ação realizada durante a sessão. **2. Inspeção do documento** O sistema automatizado da Didit já realiza uma verificação completa do documento, incluindo detecção de elementos de segurança, verificações de consistência dos dados campo a campo, validação da MRZ, verificação da data de validade e análise da qualidade da imagem. Seu papel é **avaliar os avisos sinalizados** e confirmar visualmente o documento quando necessário. 1. **Analise os avisos do documento**: confira os avisos específicos gerados pelo sistema. Avisos comuns incluem inconsistências de dados entre campos, falha na validação dos dígitos verificadores da MRZ, documentos expirados ou suspeita de adulteração. 2. **Verifique visualmente quando os avisos forem ambíguos**: se um aviso sugerir possível adulteração ou baixa qualidade de imagem, inspecione as imagens do documento diretamente. Procure sinais de edição digital, recorte, captura de tela ou manipulação física. 3. **Confira os dados extraídos por OCR**: analise os dados que o sistema extraiu do documento e confirme se parecem consistentes. O sistema destaca os campos com baixa confiança. 4. **Analise QR codes e códigos de barras decodificados**: quando o Document AI detecta um QR code ou código de barras no documento, a visualização da sessão destaca sua localização na imagem ou na pré-visualização do PDF e mostra o payload decodificado. Um código encontrado que não pôde ser decodificado aparece apenas como detectado, sem nenhum payload atribuído. Essa sobreposição de localização é separada dos destaques de aviso de manipulação do documento, que mantêm o tratamento atual. 5. **Analise as correspondências de documentos**: se a **Face Search** ou a detecção de duplicatas estiver ativada, verifique se esse usuário já foi verificado antes com outra identidade ou se o documento aparece na sua **blocklist**. > [!TIP] > > Passe o cursor sobre as imagens do documento no console da Didit para usar o **recurso de zoom** e fazer uma inspeção detalhada em nível de pixel. Isso é especialmente útil para verificar microimpressões e hologramas. **3. Verificação biométrica e de prova de vida** A Didit realiza automaticamente a **correspondência facial**, a **prova de vida** e, se ativada, a **busca facial**. Seu papel é analisar os resultados quando forem sinalizados. 1. **Pontuação de correspondência facial**: o sistema calcula uma pontuação de similaridade biométrica entre a selfie e a foto do documento. Ao analisar uma correspondência facial sinalizada, concentre-se em características estruturais como formato dos olhos, geometria do nariz, linha da mandíbula e marcas distintivas. 2. **Pontuação de prova de vida**: o sistema de prova de vida detecta ataques de apresentação, como fotos impressas, reprodução em tela, deepfakes e máscaras 3D. Câmeras de baixa qualidade ou pouca iluminação às vezes produzem pontuações mais baixas para usuários legítimos. Nesses casos, considere **solicitar o reenvio** em vez de recusar. 3. **Resultados da busca facial**: analise com cuidado qualquer correspondência: * **Detecção de duplicatas**: uma correspondência com outra sessão pode indicar que a mesma pessoa está se verificando com várias identidades. * **Correspondências com a lista de bloqueio**: se o rosto corresponder a um usuário na lista de bloqueio, isso normalmente justifica uma recusa. * **Falsos positivos**: a semelhança facial entre pessoas diferentes acontece. Avalie a pontuação de confiança e compare as imagens visualmente. **4. Análise de risco e de sinais** Navegue pelas seções **AML**, **Device & IP Analysis** e **Database Validation** para avaliar o risco contextual. ![Resultados da análise AML na revisão manual](https://mintcdn.com/didit-0f962782/ibesJiSLVa9jZb5z/images/console-manual-review-aml.png?fit=max\&auto=format\&n=ibesJiSLVa9jZb5z\&q=85\&s=f08862b7abc947edb57e81b87ff8ecac) **Triagem AML** * **Sem correspondências**: risco baixo. Nenhum resultado encontrado em listas de monitoramento globais, listas de sanções ou bases de dados de PEP. * **Correspondências encontradas**: analise cada registro correspondente. Verifique se é um verdadeiro positivo ou um falso positivo, analise a categoria da correspondência (PEP, sanções, lista de monitoramento, mídia adversa) e considere a fonte e a atualidade dos dados. * **Use as pontuações, não apenas o rótulo**: o cabeçalho da seção mostra a **Pontuação de risco** agregada da qual o status AML foi derivado (a maior pontuação de risco entre os resultados não marcados como Falso positivo, comparada com os limiares de aprovação e de revisão do fluxo de verificação). Cada linha mostra a **Pontuação de correspondência** do resultado (confiança na identidade) e a **Pontuação de risco** (risco da entidade); passe o cursor sobre qualquer uma delas para ver como foi calculada. São os mesmos `score`, `match_score` e `risk_score` que a sua integração recebe no [payload da decisão](https://docs.didit.me/pt-br/core-technology/aml-screening/report-aml-screening.md#três-pontuações-não-um-único-veredito). **Análise de dispositivo e IP e inteligência de dispositivo** * **Consistência geográfica**: compare o país emissor do documento, o endereço informado pelo usuário e a geolocalização do IP. * **Detecção VPN / Proxy**: verifique se o usuário está se conectando por meio de VPN, proxy ou rede Tor. * **Metadados do dispositivo**: analise o tipo de dispositivo, o sistema operacional e as informações do navegador em busca de anomalias. *** ## Tomando uma decisão Depois de concluir sua revisão, você tem três opções: **Aprovar**, **Recusar** ou **Solicitar Reenvio**. > [card] Aprovar > > * O documento parece autêntico e sem alterações > * Todos os campos de dados são consistentes e legíveis > * A correspondência biométrica da selfie confirma que se trata da mesma pessoa > * A pontuação da verificação de prova de vida está dentro da faixa aceitável > * Nenhuma correspondência relevante em AML, sanções ou PEP > * Os dados de dispositivo e localização são consistentes > [card] Recusar > > * O documento parece adulterado, falsificado ou alterado > * A selfie não corresponde à foto do documento > * Correspondência de AML ou sanções de alta confiança confirmada > * Fortes indícios de um ataque de apresentação > * Padrões de identidade fraudulenta detectados > * Inconsistências críticas de dispositivo ou localização > [card] Solicitar reenvio > > * Imagens do documento borradas ou de baixa qualidade > * Verificação de prova de vida com falha por problemas técnicos > * Documento errado enviado > * Etapas de verificação incompletas ou expiradas > * Problemas corrigíveis que o usuário pode resolver ![Caixa de diálogo de seleção dos critérios de recusa](https://mintcdn.com/didit-0f962782/ibesJiSLVa9jZb5z/images/console-decline-criteria.png?fit=max\&auto=format\&n=ibesJiSLVa9jZb5z\&q=85\&s=1b6056a86de8250e5e4a5cd786de4171) > [!NOTE] > > Sempre **selecione um motivo de recusa** e adicione **notas de revisão** detalhadas ao recusar uma sessão. Isso apoia a garantia de qualidade, as auditorias regulatórias e as análises internas. *** ## Solicitando um reenvio Quando uma sessão não pode ser claramente aprovada ou recusada, normalmente por causa de **problemas corrigíveis**, você pode solicitar que o usuário reenvie etapas de verificação específicas. ### Como solicitar o reenvio **1. Abra a sessão** Acesse a sessão no console da Didit. **2. Selecione Solicitar Reenvio** Abra o controle de status da sessão, escolha **Resubmitted** e selecione **Continue**. **3. Escolha os recursos a reenviar** A caixa de diálogo mostra todos os recursos não aprovados com o status atual de cada um. Marque ou desmarque etapas individuais. Recursos que nunca foram iniciados são obrigatórios automaticamente. **4. Opcionalmente, envie uma notificação por e-mail** Se o e-mail do usuário estiver disponível, envie a ele uma notificação localizada com um link direto para retomar. O e-mail informa o motivo de cada etapa; quando todas as etapas são solicitadas porque o documento expirou, ele diz isso e pede um documento válido em vez de um "tente novamente" genérico. O texto pode ser personalizado por localidade em [Marca própria → Textos](https://docs.didit.me/pt-br/console/white-label.md#texto-personalizado). **5. Visualize a prévia e confirme** Selecione **Preview** para revisar o destinatário, o remetente, o assunto e o e-mail localizado. Sessões de marca própria usam a identidade visual configurada e o remetente verificado. Selecione **Edit** para alterar as verificações, o destinatário ou o idioma e, em seguida, gere uma nova prévia. **Confirm** solicita o reenvio; apenas visualizar a prévia não altera a sessão nem envia e-mail. Se as verificações automáticas concluírem a verificação sem outra ação do usuário, o e-mail de solicitação de ação não é enviado. ### O que acontece após o reenvio 1. **Os resultados anteriores continuam legíveis**: apenas as etapas selecionadas recomeçam. O que elas retornaram antes passa a ser um envio anterior: a sessão o exibe nas abas de envio de cada etapa ("Submission 2 · latest", "Submission 1"), e a API o retorna com `?include=resubmissions` em [Retrieve Session](https://docs.didit.me/pt-br/sessions-api/retrieve-session.md). 2. **O usuário volta ao fluxo de verificação**: ele só precisa concluir as etapas específicas que foram solicitadas. 3. **A sessão permanece no status Resubmitted**: distinto de **In Progress**, o que ajuda você a acompanhar as sessões de reenvio separadamente. 4. **Reavaliação automática**: assim que todos os recursos reenviados forem concluídos, o sistema recalcula o status final automaticamente. 5. **Um novo webhook é disparado**: seu servidor recebe um webhook com o status final atualizado. > [!TIP] > > Você pode solicitar o reenvio várias vezes na mesma sessão. Cada solicitação é numerada, e todos os envios anteriores continuam legíveis, com quem os solicitou e por quê. Tentativas dentro de uma mesma etapa (por exemplo, uma segunda foto que o fluxo pediu) não são envios: a sessão mostra a tentativa mais recente e Eventos lista todas elas. Excluir a sessão exclui todos os envios. ### Reenvio vs. criar uma nova sessão | | Reenvio | Nova sessão | | - | - | - | | **ID da sessão** | O mesmo ID da sessão é mantido | Um novo ID da sessão é criado | | **Histórico** | Tentativas anteriores arquivadas na mesma sessão | Sessão separada, sem histórico vinculado | | **Esforço do usuário** | Refazer apenas as etapas com falha ou selecionadas | Verificação completa do zero | | **Impacto na conversão** | Taxas de conclusão mais altas | Risco de abandono pelo usuário | | **Webhook** | Mesmo ID da sessão, o status muda para Reenviado → status final | Novo ciclo de vida da sessão a partir de Não iniciado | | **Trilha de auditoria** | Histórico completo em um só lugar | Distribuída por várias sessões | *** ## Boas práticas de revisão > [accordion] Seja consistente > > Aplique os mesmos critérios em todas as revisões. Documente o seu raciocínio para que outros membros da equipe possam entender e reproduzir as suas decisões. > [accordion] Prefira o reenvio à recusa para problemas corrigíveis > > Se o problema for uma foto desfocada ou um erro técnico, solicitar o reenvio preserva a sessão e evita atritos desnecessários para usuários legítimos. > [accordion] Use o recurso de zoom > > Sempre amplie as imagens do documento para verificar adulterações sutis, microimpressões ou elementos de segurança que não ficam visíveis nos níveis de zoom padrão. > [accordion] Cruze os dados > > Não avalie os sinais isoladamente. Uma pontuação de prova de vida baixa, combinada com uma conexão VPN e uma geolocalização divergente, é mais preocupante do que qualquer fator isolado. > [accordion] Documente tudo > > Adicione notas de revisão detalhadas a cada decisão, principalmente às recusas. Essas notas apoiam o controle de qualidade interno e as auditorias regulatórias, além de ajudar a treinar novos membros da equipe. > [accordion] Configure alertas > > Configure alertas por e-mail ou Slack para ser notificado imediatamente quando as sessões entrarem no status **In Review**. Tempos de resposta rápidos melhoram tanto a conformidade quanto a experiência do usuário. > [accordion] Monitore os padrões de reenvio > > Se um usuário tiver vários ciclos de reenvio, revise todo o histórico com atenção. Falhas repetidas no mesmo recurso podem indicar um problema sistêmico. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.