Como ler um resultado de verificação
O resultado de uma sessão é um status, mais um resultado por verificação, mais uma lista de avisos - os avisos são a parte que te diz o que realmente aconteceu.
Leia nesta ordem: o status geral, depois os status por verificação, depois os avisos. Os avisos são a única parte que te diz por quê - todo o resto só te diz o quê.
Abra qualquer sessão em Verifications no Business Console e você vê as mesmas três camadas, seja no console, em um payload de webhook, ou em uma resposta de API.
- Comece aqui: a decisão, e as verificações que a produziram.
- Liveness traz o resultado da selfie e a pontuação de reconhecimento facial.
- A aba do documento mostra o que foi extraído e quais campos combinaram.
- Events explica como a sessão chegou ao status atual.
#Camada 1 - o status geral
O veredito único da sessão: Approved, Declined, In Review, e assim por diante. É nisso que a maioria das integrações age. É um agregado: vem da combinação do resultado de cada verificação, conforme a configuração do seu workflow, então ele nunca te diz sozinho qual verificação foi responsável.
#Camada 2 - um resultado por verificação
Cada verificação executada tem seu próprio status e seus próprios dados. As que você vai ver com mais frequência:
| Verificação | O que observar |
|---|---|
| Verificação de ID | Campos extraídos (nome, número do documento, datas), tipo e país do documento, e se o MRZ validou |
| Prova de vida passiva / ativa | Se um humano vivo foi detectado, e qualquer sinal de ataque |
| Reconhecimento facial 1:1 | A pontuação de similaridade entre a selfie e a foto do documento |
| Busca facial 1:N | Se esse rosto corresponde a um usuário já verificado ou a uma entrada da blocklist |
| Triagem AML | As ocorrências, cada uma com uma pontuação de correspondência e uma pontuação de risco |
| Análise de dispositivo e IP | País, sinais de VPN ou proxy, endereços na blocklist |
| Comprovante de endereço | O endereço extraído e o quanto ele correspondeu ao que você informou |
| NFC | Se o chip foi lido e se a assinatura dele encadeou até um emissor confiável |
| Telefone / e-mail | Se o OTP foi confirmado, além de sinais de risco no número ou no endereço |
Uma verificação pode estar Approved enquanto a sessão está Declined, e vice-versa. Isso é normal - o status da sessão é a combinação, não o pior caso.
#Camada 3 - os avisos
Os avisos são a camada que realmente explica o resultado. Cada um é um código específico e nomeado, associado à verificação que o gerou - por exemplo:
DOCUMENT_EXPIRED- a data de validade do documento já passou.MRZ_VALIDATION_FAILED- o checksum da zona de leitura mecânica não fechou. Um forte sinal de adulteração.LOW_FACE_MATCH_SIMILARITY- a selfie e a foto do documento pontuaram abaixo do seu limiar.LIVENESS_FACE_ATTACK- um ataque de apresentação foi detectado durante a selfie.POSSIBLE_MATCH_FOUND- o AML encontrou uma ocorrência candidata que precisa ser resolvida.NFC_DATA_DOES_NOT_MATCH_OCR- o chip e os dados impressos divergem.IP_ADDRESS_IN_BLOCKLIST- a conexão veio de um endereço que você bloqueia.
Quando você está depurando uma sessão específica, vá direto para os avisos. O status te dá a conclusão; os avisos te dão a evidência. Todo catálogo de avisos por funcionalidade está documentado em core technology.
#Dados extraídos vs. o que você esperava
Se você enviou expected_details ao criar a sessão - um nome, uma data de nascimento, um número de documento que você já tinha - o resultado também te diz se o documento concordou com isso. Uma divergência aí costuma ser um problema de digitação do seu lado, e não um documento fraudulento, então vale a pena checar antes de reprovar alguém.
Nomes extraídos podem estar transliterados. Um documento em cirílico, árabe, ou grego gera um nome em script latino que pode não bater com os seus registros caractere por caractere, mesmo sendo a mesma pessoa. Compare também pelo número do documento ou pela data de nascimento antes de tratar uma divergência de nome como fraude.
#Resultados de sandbox parecem um pouco diferentes
Em uma sessão de sandbox, o console marca as seções de dados extraídos com um chip de Simulated data. A mídia foi capturada de verdade, mas os campos e o resultado vieram do cenário que você escolheu - então não tire conclusões dos valores em si. Veja testar no sandbox.
#Obtendo a mesma coisa de forma programática
O payload do webhook e o GET /v3/session/{id}/decision/ trazem as três camadas em um único objeto decision. Trate o webhook como sua fonte da verdade e use o polling apenas para reconciliação - alguns eventos, como edições de dados feitas por um revisor, só chegam por webhook. Veja obtendo resultados com webhooks.
#Obtendo uma cópia para seus registros
Para auditorias e registros regulatórios, baixe a sessão como PDF - ele reúne todas as etapas, os dados extraídos, as pontuações biométricas, os resultados de AML, e a decisão final. Veja baixando um relatório de verificação.