Começar
Integrar / SDKs
Verificação de utilizadores
Verificação de empresas
Monitorização de transações
Registo de alteraçõesVisão geral
Os avisos no relatório de verificação de identidade sinalizam cada condição observada pela Didit durante a leitura e validação do documento. Ficam disponíveis no arraywarnings[] em cada item de id_verifications[] (consulte Relatório de verificação de identidade), com a estrutura descrita em Modelos de dados — Objeto de aviso: feature, risk, additional_data, log_type, short_description, long_description, node_id.
Cada aviso tem três camadas:
- O código
risk— um identificador estável que pode utilizar para fazer correspondências 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 coisa →information. - O impacto na decisão — definido pelos grupos de risco configuráveis do fluxo. O mesmo código
riskpode ser encaminhado para Aprovar, Revisão ou Recusar, dependendo de como a sua aplicação está configurada.
Condições de recusa automática
Nos fluxos, os seguintes riscos fazem sempre com que o relatório de verificação de identidade (e a sessão) fique com o estadoDeclined. Não podem ser configurados:
Para a API OCR autónoma, 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 (o valor predefinido é Recusar) e os três riscos de prova de vida do documento baseiam-se em limiares (ver abaixo).
Os riscos configuráveis dessa API aceitam DECLINE ou NO_ACTION como parâmetros do pedido, em vez de um veredito de Revisão. O único resultado de Revisão que pode devolver não é configurável: quando uma verificação solicitada de prova de vida do documento não gera uma pontuação utilizável, a resposta é In Review com um aviso DOCUMENT_LIVENESS_NOT_COMPUTED (consulte Prova de vida do documento).
Definições de verificação configuráveis
Na consola da Didit, os restantes riscos de identificação estão agrupados em definições que pode encaminhar para Aprovar, Revisão ou Recusar (por fluxo de verificação e por nó em fluxos com grafos):
Os riscos de duplicados e da lista de bloqueio da captura silenciosa são provenientes da Pesquisa facial na selfie tirada durante a captura do documento. A pesquisa é executada enquanto a Pesquisa facial com captura silenciosa (
document_selfie_face_search_enabled) estiver ativada, o que corresponde à predefinição, e a Pesquisa facial não estiver desativada no passo de Prova de vida; caso contrário, nenhum destes seis riscos é gerado.
Duas famílias de riscos de identificação são baseadas em limiares em vez de opções de Aprovar/Revisão/Recusar:
- Prova de vida do documento —
SCREEN_CAPTURE_DETECTED,PRINTED_COPY_DETECTED,PORTRAIT_MANIPULATION_DETECTED. Cada tipo de fraude tem os 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 análise; caso contrário,information. - Correspondência facial entre câmaras —
LOW_FRONT_CAMERA_FACE_MATCH_SIMILARITY, regida pordocument_selfie_portrait_match_decline_threshold/document_selfie_portrait_match_review_threshold.
Configurar limiares de prova de vida do documento
No editor de fluxos, estes limiares encontram-se no separador Falsificação do passo de Verificação de identidade, com um cartão por tipo de fraude: Substituição do retrato, Cópia impressa e Captura de ecrã. Cada verificação atribui ao documento uma pontuação de0 a 100 relativamente à sua autenticidade aparente. Uma pontuação mais elevada significa que o documento tem maior probabilidade de ser genuíno. Os dois valores num cartão dividem essa escala em três intervalos:
Aumentar qualquer um dos valores torna a verificação mais rigorosa: mais sessões passam para o intervalo superior. Reduzir um valor permite que mais sessões avancem. No editor, o valor de Recusar não pode ultrapassar o valor de Revisão. Através da API, um valor de Recusar superior ao valor de Revisão remove o intervalo de Em análise.
Predefinições da plataforma, utilizadas quando um fluxo não define um valor:
Comece pelas predefinições e ajuste um valor de cada vez. Cada cartão apresenta a respetiva predefinição e um botão Repor predefinição, para que possa sempre voltar a ela. O editor também alerta sobre estas configurações:
- Revisão a
100. Apenas uma pontuação perfeita é aprovada, pelo que quase todas as sessões passam para Em análise ou são recusadas. - Recusar a
100. Apenas uma pontuação perfeita evita uma recusa, pelo que quase todas as sessões são recusadas. - Ambos os valores a
0. Nenhuma pontuação é alguma vez assinalada, pelo que a verificação fica efetivamente desativada.
SCREEN_CAPTURE_DETECTED é comunicado.
A correspondência facial entre câmaras utiliza a mesma lógica com uma diferença no limite: uma pontuação igual ao respetivo limiar de revisão ainda passa para Em análise.
Quatro riscos de identificação não são configuráveis nem dependentes de limiares. POSSIBLE_FRONT_CAMERA_FACE_IN_BLOCKLIST é sempre encaminhado para Revisão: uma selfie que esteja próxima de um rosto presente na lista de bloqueio, sem constituir uma correspondência confirmada, deve ser avaliada por uma pessoa, nunca originando uma recusa automática nem sendo ignorada. BARCODE_SIGNATURE_INVALID é sempre encaminhado para Revisão. Só é acionado quando um código de barras contém a assinatura de uma autoridade emissora que falha a verificação criptográfica, pelo que não existe qualquer configuração na qual uma falsificação comprovada seja ignorada. DOCUMENT_BACK_SIDE_NOT_AVAILABLE é sempre informativo e nunca afeta a decisão: comunica uma limitação do catálogo de documentos da Didit, e não uma propriedade do documento apresentado, pelo que não existe qualquer configuração na qual possa recusar ou colocar em revisão um titular legítimo.
FRONT_CAMERA_CAPTURED_DOCUMENT é sempre encaminhado para Revisão.
Só é acionado quando a captura da câmara frontal realizada durante a leitura do documento mostra um documento de identidade e nenhuma pessoa, garantindo que uma captura que nada indica sobre quem segurava o documento chega sempre a um operador humano.
É verificado sempre que a correspondência da selfie na captura de documentos (is_document_selfie_portrait_match_enabled) está ativada.
Avisos gerados
Verificado em relação acollect_ocr_logs, ao fluxo de captura de documentos e a process_ocr_logs_and_get_status. As descrições curtas abaixo são as strings exatas de short_description devolvidas pela API.
Reconhecimento e qualidade do documento
O fluxo de captura também pode rejeitar um carregamento com os códigos de feedback
IMAGE_RESOLUTION_TOO_LOW, DOCUMENT_NOT_FULLY_VISIBLE, IMAGE_QUALITY_TOO_LOW e DOCUMENT_OCCLUSION_DETECTED (determina-se que um dedo ou objeto está fisicamente a cobrir texto impresso). Cada um solicita uma nova tentativa no SDK e é registado no relatório como o seu próprio risco, encaminhado pelas definições de Image Quality — DOCUMENT_OCCLUSION_DETECTED e IMAGE_QUALITY_TOO_LOW partilham a mesma ação. Descrevem a captura: uma nova tentativa bem-sucedida limpa o aviso. A questão de saber se um campo coberto deve afetar a decisão é tratada pelo aviso separado de integridade CRITICAL_FIELD_OCCLUSION_DETECTED abaixo, que é gerado no momento da decisão e é Review por predefinição.Extração de campos
MRZ, QR, código de barras
Os três riscos de MRZ são ignorados para tipos de documentos com MRZs reconhecidamente não fiáveis.A verificação de assinatura de código de barras abrange atualmente os cartões de identidade nacionais franceses, cujo código de barras 2D-Doc ANTS é assinado pela autoridade emissora. O
BARCODE_SIGNATURE_INVALID é gerado apenas quando a própria verificação da assinatura rejeita o payload. Um código de barras sem assinatura, assinado por uma autoridade que ainda não conste no repositório de confiança da Didit, ou cuja assinatura não possa ser descodificada, é tratado como dados não autenticados e validado contra a MRZ e o texto impresso como anteriormente, sem gerar este risco.Os códigos de barras das cartas de condução 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, pelo que a Didit apenas deteta e regista se um payload possui uma assinatura; a assinatura em si nunca é verificada. As falhas de assinatura AAMVA não constituem um sinal de risco atualmente. Um payload AAMVA adulterado só surge como BARCODE_VALIDATION_FAILED, e apenas se a adulteração também fizer com que o código de barras discorde da MRZ ou dos dados impressos/OCR - um payload internamente consistente com uma assinatura falsificada passa sem qualquer sinal.Nunca é pedido ao utilizador que efetue uma nova captura em caso de BARCODE_SIGNATURE_INVALID: uma assinatura que não corresponda ao payload não pode ser corrigida tirando uma fotografia melhor.Correspondência de identidade
Prova de vida do documento (adulteração)
Definido por limiares para cada tipo de fraude nos fluxos. Na API de OCR autónoma, estes três riscos resultam sempre numa recusa, e uma verificação solicitada que não produza uma pontuação utilizável devolveIn Review em vez de aprovar.
As próprias pontuações constam em todos os relatórios V3 como document_liveness, incluindo quando nenhum aviso foi acionado, para que um documento aprovado possa ainda ser auditado.
Integridade do canal de captura
O
log_type reflete a ação configurada: error para Recusar, warning para Revisão, information para Nenhuma ação.
Ação recomendada: trate uma sessão recusada como uma captura injetada e peça à pessoa para tentar novamente num dispositivo físico com a respetiva câmara incorporada.
Os sinais que uma pessoa genuína pode produzir nunca desencadeiam INJECTION_ATTACK_DETECTED e permanecem informativos.
Aplicações que retransmitem uma câmara real, como um telemóvel utilizado como webcam ou uma camada de efeitos sobre uma webcam real, não são reportadas como ataques de injeção.
Esta é a deteção de ataques de injeção, que é distinta da deteção de ataques de apresentação (uma falsificação apresentada a uma câmara real).
Imagens de documentos públicos conhecidas
Discrepâncias em relação aos detalhes esperados
Ao passarexpected_details para uma sessão, a Didit gera um aviso de discrepância para cada campo que não corresponda. Um agrupamento (expected_details_mismatch_action, Revisão por predefinição) controla o encaminhamento para todos estes:
Cada aviso de discrepância inclui os valores esperados e extraídos em
additional_data.
Idade
Morada
Correspondências de documentos entre sessões
Além dos avisos acima, o relatório de ID 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 altamente semelhante (os documentos na lista de bloqueio exigem adicionalmente uma correspondência exata do número do documento), excluindo sessões que pertençam ao mesmo utilizador. Os documentos adicionados à sua lista de bloqueio aparecem com is_blocklisted: true. Os documentos na sua lista de permissões continuam a aparecer nas correspondências, mas a ação para utilizadores duplicados é ignorada.
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 um front_image_url assinado.
Exemplos
Aviso configurável no seu encaminhamento predefinido (informação)
Recusa automática em documento expirado
Discrepância em relação aos detalhes esperados com payload
Tipos de aviso
A cada risco é atribuída uma gravidade com base na configuração da sua aplicação. As três gravidades são:Relacionado
- Relatório de verificação de identidade — esquema completo do relatório e estados.
- Monitorização de documentos — como a Didit deteta adulterações e duplicados entre sessões.
- Webhooks —
session.status.updatedtransporta os avisos assim que o passo de ID 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[].