Primeiros passos
Integração / SDKs
Verificação de usuários
Verificação de empresas
Monitoramento de transações
Registro de alteraçõesVisão geral
Os avisos no relatório de verificação de identidade sinalizam cada condição que a Didit observou ao ler e validar o documento. Eles ficam no arraywarnings[] de cada item de id_verifications[] (veja Relatório de verificação de identidade), com o formato descrito em Modelos de dados: objeto Warning: feature, risk, additional_data, log_type, short_description, long_description, node_id.
Todo aviso tem três camadas:
- O código
risk: um identificador estável que você pode usar para identificar no seu código. - O
log_type: derivado da ação que a sua configuração atribui ao risco no momento da avaliação: Recusar →error, Revisão →warning, qualquer outra →information. - O impacto na decisão: definido pelos grupos de risco configuráveis do fluxo de verificação (workflow). O mesmo código
riskpode ser direcionado para Aprovar, Revisão ou Recusar, dependendo de como a sua aplicação está configurada.
Condições de recusa automática
Nos fluxos, os riscos a seguir sempre fazem com que o relatório de identidade (e a sessão) seja definido comoDeclined. Eles não podem ser configurados:
Na API de OCR avulsa, o conjunto de recusa incondicional é
DOCUMENT_EXPIRED, MINIMUM_AGE_NOT_MET, PORTRAIT_IMAGE_NOT_DETECTED, SCREEN_CAPTURE_DETECTED, PRINTED_COPY_DETECTED, PORTRAIT_MANIPULATION_DETECTED e PUBLIC_DOCUMENT_IMAGE_DETECTED. Nos fluxos, a idade mínima é configurável (padrão Recusar) e os três riscos de prova de vida do documento dependem de limiares (veja abaixo).
Os riscos configuráveis dessa API aceitam DECLINE ou NO_ACTION como parâmetros da requisição, em vez de um veredito de revisão. O único resultado de Revisão que ela pode retornar não é configurável: quando uma verificação de prova de vida do documento solicitada não produz uma pontuação utilizável, a resposta é In Review com um aviso DOCUMENT_LIVENESS_NOT_COMPUTED (veja Prova de vida do documento).
Configurações de verificação ajustáveis
No console da Didit, os demais riscos de identidade são agrupados em configurações que você pode direcionar para Aprovar, Revisão ou Recusar (por fluxo e, nos fluxos em grafo, por nó):
Os riscos de duplicidade na captura silenciosa e de lista de bloqueio vêm da Busca facial na selfie tirada durante a captura do documento. A busca é executada enquanto a Busca facial com captura silenciosa (
document_selfie_face_search_enabled) está ativada, que é o padrão, e a Busca facial não está desativada na etapa de Prova de vida; caso contrário, nenhum desses seis riscos é gerado.
Duas famílias de riscos de identidade são controladas por limiares, em vez de alternâncias entre Aprovar/Revisão/Recusar:
- Prova de vida do documento —
SCREEN_CAPTURE_DETECTED,PRINTED_COPY_DETECTED,PORTRAIT_MANIPULATION_DETECTED. Cada tipo de fraude tem seus próprios limiares de recusa e de revisão: pontuação abaixo do limiar de recusa →error+ Recusada; abaixo do limiar de revisão →warning+ Em revisão; caso contrário,information. - Correspondência facial entre câmeras —
LOW_FRONT_CAMERA_FACE_MATCH_SIMILARITY, regida pordocument_selfie_portrait_match_decline_threshold/document_selfie_portrait_match_review_threshold.
Configurar os limiares de prova de vida do documento
No editor de fluxos, esses limiares ficam na aba Falsificação da etapa de Verificação de identidade, com um cartão por tipo de fraude: Substituição do retrato, Cópia impressa e Captura de tela. Cada verificação atribui ao documento uma pontuação de0 a 100 que indica o quanto ele parece autêntico. Quanto maior a pontuação, maior a probabilidade de o documento ser autêntico. Os dois valores de um cartão dividem essa escala em três faixas:
Aumentar qualquer um dos valores torna a verificação mais rigorosa: mais sessões caem na faixa acima dele. Diminuir um valor deixa passar mais sessões. No editor, o valor de Recusar não pode ultrapassar o valor de Revisão. Pela API, um valor de Recusar acima do valor de Revisão elimina a faixa Em revisão.
Padrões da plataforma, usados quando um fluxo não define um valor:
Comece pelos padrões e altere um valor de cada vez. Cada cartão mostra seu padrão e um botão Restaurar padrão, para que você sempre possa voltar a ele. O editor também avisa sobre estas configurações:
- Revisão em
100. Só uma pontuação perfeita é aprovada, então quase todas as sessões vão para Em revisão ou são recusadas. - Recusar em
100. Só uma pontuação perfeita evita a recusa, então quase todas as sessões são recusadas. - Os dois valores em
0. Nenhuma pontuação é sinalizada, então a verificação fica, na prática, desativada.
SCREEN_CAPTURE_DETECTED é reportado.
A correspondência facial entre câmeras segue a mesma lógica, com uma diferença no limite: uma pontuação igual ao seu limiar de revisão ainda vai para Em revisão.
Quatro riscos de ID não são configuráveis nem dependem de limiares. POSSIBLE_FRONT_CAMERA_FACE_IN_BLOCKLIST sempre direciona para Revisão: uma selfie parecida com um rosto da lista de bloqueio, sem ser uma correspondência confirmada, deve ser avaliada por uma pessoa, nunca recusada automaticamente e nunca ignorada. BARCODE_SIGNATURE_INVALID sempre direciona para Revisão. Ele só é disparado quando um código de barras traz uma assinatura da autoridade emissora que falha na verificação criptográfica, portanto não existe configuração em que uma falsificação comprovada seja ignorada. DOCUMENT_BACK_SIDE_NOT_AVAILABLE é sempre informação e nunca afeta a decisão: ele indica uma limitação do catálogo de documentos da Didit, não uma propriedade do documento apresentado, portanto não existe configuração em que ele possa recusar um titular legítimo ou enviá-lo para revisão.
FRONT_CAMERA_CAPTURED_DOCUMENT sempre direciona para Revisão.
Ele só é disparado quando o quadro da câmera frontal capturado durante a leitura do documento mostra um documento de identidade e nenhuma pessoa, portanto uma captura que não diz nada sobre quem segurava o documento é sempre encaminhada para análise humana.
Ele é verificado sempre que a correspondência de selfie na captura do documento (is_document_selfie_portrait_match_enabled) está ativada.
Avisos gerados
Verificado com base emcollect_ocr_logs, no fluxo de captura de documentos e em process_ocr_logs_and_get_status. As descrições curtas abaixo são as strings short_description exatas retornadas pela API.
Reconhecimento e qualidade do documento
O fluxo de captura também pode rejeitar um envio com os códigos de feedback
IMAGE_RESOLUTION_TOO_LOW, DOCUMENT_NOT_FULLY_VISIBLE, IMAGE_QUALITY_TOO_LOW e DOCUMENT_OCCLUSION_DETECTED (quando se avalia que um dedo ou objeto está cobrindo fisicamente o texto impresso). Cada um deles solicita uma nova captura no SDK e é registrado no relatório como um risco próprio, direcionado pelas configurações de Image Quality: DOCUMENT_OCCLUSION_DETECTED e IMAGE_QUALITY_TOO_LOW compartilham uma mesma ação. Eles descrevem a captura: uma nova captura bem-sucedida remove o aviso. Se um campo coberto deve ou não afetar a decisão é definido separadamente pelo CRITICAL_FIELD_OCCLUSION_DETECTED, do lado da integridade, descrito abaixo, que é gerado no momento da decisão e tem Review como padrão.Extração de campos
MRZ, QR, código de barras
Os três riscos de MRZ são ignorados para tipos de documento com MRZs reconhecidamente pouco confiáveis.Atualmente, a verificação de assinatura de código de barras abrange as carteiras de identidade nacionais francesas, cujo código de barras 2D-Doc da ANTS é assinado pela autoridade emissora.
BARCODE_SIGNATURE_INVALID é gerado somente quando a própria verificação de assinatura rejeita o payload. Um código de barras sem assinatura, assinado por uma autoridade que ainda não está no repositório de confiança da Didit, ou cuja assinatura não pode ser decodificada é tratado como dados não autenticados e validado em relação à MRZ e ao texto impresso como antes, sem gerar este risco.Os códigos de barras de carteiras de motorista dos EUA e do Canadá (AAMVA) não são verificados criptograficamente: a assinatura digital nesses casos é opcional e específica de cada jurisdição, e nenhuma jurisdição publica chaves de verificação, por isso a Didit apenas detecta e registra se um payload contém uma assinatura; a assinatura em si nunca é verificada. Falhas de assinatura AAMVA não são um sinal de risco hoje. Um payload AAMVA adulterado só aparece como BARCODE_VALIDATION_FAILED, e somente se a adulteração também fizer o código de barras divergir da MRZ ou dos dados impressos/de OCR - uma assinatura falsificada em um payload internamente consistente passa sem nenhum sinal.O usuário nunca é solicitado a refazer a captura em caso de BARCODE_SIGNATURE_INVALID: uma assinatura que não corresponde ao payload não pode ser corrigida tirando uma foto melhor.Correspondência de identidade
Prova de vida do documento (adulteração)
Definido por limiar para cada tipo de fraude nos fluxos. Na API de OCR independente, esses três riscos recusam incondicionalmente, e uma verificação solicitada que não produz uma pontuação utilizável retornaIn Review em vez de aprovar.
As próprias pontuações aparecem em todo relatório V3 como document_liveness, inclusive quando nenhum aviso foi gerado, para que um documento aprovado ainda possa ser auditado.
Integridade do canal de captura
O
log_type reflete a ação configurada: error para Recusar, warning para Revisão e information para Nenhuma ação.
Ação recomendada: trate uma sessão recusada como uma captura injetada e peça à pessoa que tente novamente em um dispositivo físico, usando a câmera integrada dele.
Sinais que uma pessoa real pode produzir nunca geram INJECTION_ATTACK_DETECTED e permanecem informativos.
Aplicativos que retransmitem uma câmera real, como um celular usado como webcam ou uma camada de efeitos sobre uma webcam real, não são reportados como ataques de injeção.
Trata-se da detecção de ataques de injeção, que é diferente da detecção de ataques de apresentação (uma falsificação apresentada a uma câmera real).
Imagens públicas conhecidas de documentos
Divergências com os dados esperados
Quando você enviaexpected_details para uma sessão, a Didit gera um aviso de divergência para cada campo que não corresponde. Um único agrupamento (expected_details_mismatch_action, padrão Revisão) controla o encaminhamento de todos eles:
Cada aviso de divergência traz os valores esperados e extraídos em
additional_data.
Idade
Endereço
Correspondências de documentos entre sessões
Além dos avisos acima, o relatório de identidade V3 inclui um arraymatches[]: até 5 outros documentos na sua aplicação com a mesma data de nascimento, o mesmo país emissor e um nome completo muito semelhante (documentos na lista de bloqueio exigem, além disso, correspondência exata do número do documento), excluindo as sessões que pertencem ao mesmo usuário. Os documentos adicionados à sua lista de bloqueio aparecem com is_blocklisted: true. Os documentos na sua lista de permissões continuam aparecendo nas correspondências, mas a ação para usuário duplicado não é aplicada.
Cada correspondência inclui session_id, session_number, vendor_data, verification_date, user_details (name, document_type, document_number), status, is_blocklisted, api_service e uma front_image_url assinada.
Exemplos
Aviso configurável em seu roteamento padrão (informação)
Recusa automática por documento expirado
Divergência entre os dados esperados e o payload
Tipos de aviso
Cada risco recebe um nível de severidade com base na configuração da sua aplicação. As três severidades são:Relacionados
- Relatório de verificação de identidade — esquema completo do relatório e status.
- Monitoramento de documentos — como a Didit detecta adulterações e duplicatas entre sessões.
- Webhooks — o
session.status.updatedtraz os avisos assim que a etapa de identidade termina. - Modelos de dados — Verificação de identidade — esquema canônico, campo a campo.
- Modelos de dados — Objeto de aviso — a estrutura de cada entrada em
warnings[].