Prova de vida e biometrias na jornada

verify

O que é. Módulo de Autenticação (prova de vida e biometrias). Na API o passo é verify. Roda como etapa própria da jornada, independente do requisito de autenticação do envelope de Assinatura. O que foi aprovado aqui não libera automaticamente a assinatura na API da Clicksign, e o contrário também vale.

O que faz. Coleta a prova de presença e, conforme o tipo, a face, em webview. Quando compara identidade, o retorno diz se a face corresponde ao CPF enviado. Não descobre de quem é a face. O Flow declara o tipo de autenticação e, se quiser, a ordem de tentativa dos fornecedores. O módulo executa e devolve o resultado.

Três tipos

• liveness. Prova de vida (liveness). Na API v3, este tipo se chama selfie dinâmica. O desfecho é aprovado ou reprovado. Não há resultado inconclusivo. Admite caf e clearsale, então provider_priority tem efeito prático.
• biometric_behavior. Biometria comportamental, no modelo 1:N. Três resultados na mesma captura: prova de vida, identidade e alerta de comportamento. A identidade compara a face capturada com a base do fornecedor, usando o CPF enviado. A pessoa não digita o CPF nem envia foto de RG ou CNH. Quem integra envia nome e CPF no disparo, ou mapeia os dois a partir de um formulário anterior. O alerta indica se aquela face tem histórico suspeito, por exemplo tentativa com CPFs diferentes. Produz o sinal de alerta de fraude (identity_fraudsters_result) que o KYC consome. Sem este tipo antes, um passo kyc falha na execução. A publicação do flow não valida essa sequência.
• identity_biometrics. Biometria (base ampliada). É a validação de identidade: a mesma captura da biometria comportamental, sem o alerta de comportamento. Nome e CPF também são obrigatórios, no disparo ou num formulário anterior. A etapa segue só quando a prova de vida e a identidade vêm aprovadas. O alerta de comportamento não entra. Não habilita KYC depois.

Fornecedores

A lista abaixo é a que vale hoje. Os fornecedores de cada tipo podem mudar.

* o type caf corresponde ao fornecedor "Certta".

provider_priority é um array opcional com a ordem de tentativa, o mais prioritário primeiro.

O que o passo declara

O passo verify leva authentication e, se houver um form antes, pode casar campos coletados com a identidade via contact_fields_map.

instructions é opcional. A tela de instruções aparece antes da captura. Só instructions: false a oculta. Omitir o campo mantém a tela. O Flow não desenha nem customiza essa tela. Conteúdo e layout são do módulo.

Schema do context: Orquestrador.

O que cada resultado significa

A mesma captura pode devolver prova de vida, identidade e comportamento. A biometria comportamental usa as três. A biometria (base ampliada) usa prova de vida (liveness) e identidade (identity_verification), com o mesmo desfecho na esteira, e não lê o comportamento (risk_signals). A consulta compara a face capturada com o CPF enviado. Ela não descobre de quem é a face.

Quando a biometria comportamental segue

A combinação abaixo é a padrão de quem usa biometric_behavior na esteira. Reprovação, no padrão, encerra a jornada sem nova tentativa. Retentativa automática seria vetor de fraude.

Identidade inconclusive encerra a etapa, no mesmo desfecho de uma identidade reprovada. O alerta pode não vir quando a identidade ficou inconclusiva. A ausência do alerta, por si, não encerra a etapa. Prova de vida ou identidade ausentes encerram, porque o resultado ficou incompleto.

Para usar outra combinação, contrate o Módulo de KYC. O caso mais comum é deixar a identidade inconclusiva seguir. Nesse desenho, o passo biometric_behavior precisa de result_policy: "passthrough", para a reprovação não encerrar a jornada antes do KYC.

Quando a biometria (base ampliada) segue

No tipo identity_biometrics, a etapa segue só com as duas confirmações: a pessoa está viva e a face corresponde ao CPF. Sem uma das duas, a jornada para. Não há nova tentativa na mesma execução.

Quando a identidade fica inconclusiva, o resultado pode trazer risk_score (0–100). Esse número fica no registro e não decide se a etapa segue.

No WhatsApp, a pessoa recebe o aviso de rejeição da prova de vida ou da identidade, conforme o que falhou.

passthrough

Com result_policy: "passthrough", a reprovação conclui a etapa, a execução segue e o template de rejeição do WhatsApp não é enviado. O veredito fica registrado e não é aplicado. Na biometria comportamental, identidade inconclusive entra nessa reprovação. É o caminho quando o KYC arbitra o desfecho.

Na biometria (base ampliada), prova de vida rejected ou identidade rejected ou inconclusive conclui a etapa e a jornada segue. O veredito fica registrado e o template de rejeição do WhatsApp não é enviado. Prova de vida ou identidade ausente, resultado incompleto ou falha do fornecedor encerra a etapa e a execução mesmo com passthrough.

passthrough cobre reprovação, que é um resultado negativo válido. Não cobre falha operacional do fornecedor, sem resultado ou com resultado incompleto. Essa falha encerra o passo e a execução.

Próximo passo ➡️

• Módulo de KYC — a conta configura outra combinação desses resultados.
• Módulos — volte ao mapa da jornada.
• Orquestrador — schema do passo.
• FAQ: dúvidas em ClickFlow — respostas curtas para as dúvidas mais comuns.