Como ler um resultado de verificação
O resultado de uma sessão é um estado mais um resultado por comprovação mais uma lista de avisos - os avisos são a parte que te diz o que realmente aconteceu.
Lê pela seguinte ordem: o estado geral, depois os estados por comprovação, depois os avisos. Os avisos são a única parte que te diz porquê - tudo o resto só te diz o quê.
Abre qualquer sessão em Verificações na Consola de Negócio e obténs as mesmas três camadas, quer estejas a olhar para a consola, para o payload de um webhook, ou para uma resposta da API.
- Começa aqui: a decisão, e as comprovações que a produziram.
- Liveness contém o resultado da selfie e a pontuação de correspondência facial.
- O separador do documento mostra o que foi extraído e que campos coincidiram.
- Events explica como a sessão chegou ao seu estado atual.
#Camada 1 - o estado geral
O veredito único da sessão: Aprovada, Recusada, Em Revisão, e assim por diante. É nisto que a maioria das integrações se baseia para agir. É um agregado: resulta de combinar o resultado de cada comprovação de acordo com a forma como o teu fluxo de trabalho está configurado, por isso nunca te diz sozinho qual comprovação foi responsável.
#Camada 2 - um resultado por comprovação
Cada comprovação que correu tem o seu próprio estado e os seus próprios dados. As que vais ver com mais frequência:
| Comprovação | O que consultar |
|---|---|
| Verificação de identidade | Campos extraídos (nome, número do documento, datas), tipo de documento e país, e se a MRZ validou |
| Prova de vida passiva / ativa | Se foi detetado um ser humano vivo, e qualquer sinal de ataque |
| Correspondência facial 1:1 | A pontuação de semelhança entre a selfie e a fotografia do documento |
| Pesquisa facial 1:N | Se esta cara corresponde a um utilizador já verificado ou a uma entrada na lista de bloqueio |
| Cribagem AML | As ocorrências encontradas, 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 lista de bloqueio |
| Comprovativo de morada | A morada extraída e o quanto correspondeu à que forneceste |
| NFC | Se o chip foi lido e se a sua assinatura encadeou até um emissor de confiança |
| Telefone / e-mail | Se o OTP foi confirmado, mais sinais de risco sobre o número ou a morada |
Uma comprovação pode estar Aprovada enquanto a sessão está Recusada, e vice-versa. Isso é normal - o estado 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 à comprovaçã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 ótica não bateu certo. Um forte sinal de adulteração.LOW_FACE_MATCH_SIMILARITY- a selfie e a fotografia do documento pontuaram abaixo do teu limiar.LIVENESS_FACE_ATTACK- foi detetado um ataque de apresentação durante a selfie.POSSIBLE_MATCH_FOUND- a AML encontrou uma possível ocorrência que precisa de ser resolvida.NFC_DATA_DOES_NOT_MATCH_OCR- o chip e os dados impressos não coincidem.IP_ADDRESS_IN_BLOCKLIST- a ligação veio de um endereço que tens bloqueado.
Quando estiveres a investigar uma sessão específica, vai diretamente aos avisos. O estado dá-te a conclusão; os avisos dão-te a evidência. Todos os catálogos de avisos por funcionalidade estão documentados em core technology.
#Dados extraídos vs. o que esperavas
Se passaste expected_details ao criar a sessão - um nome, uma data de nascimento, um número de documento que já tinhas - o resultado também te diz se o documento concordava com isso. Uma discrepância aí costuma ser um problema de introdução de dados do teu lado em vez de um documento fraudulento, por isso vale a pena verificar antes de recusares alguém.
Os nomes extraídos podem estar transliterados. Um documento em escrita cirílica, árabe ou grega produz um nome em escrita latina que pode não corresponder aos teus registos carácter a carácter, mesmo sendo a mesma pessoa. Compara também pelo número de documento ou pela data de nascimento antes de tratares uma discrepância de nome como fraude.
#Os resultados em sandbox parecem ligeiramente diferentes
Numa sessão sandbox, a consola assinala as secções de dados extraídos com um chip de Dados simulados. A media foi captada de verdade, mas os campos e o resultado vieram do cenário que escolheste - por isso não tires conclusões dos valores em si. Consulta testar em sandbox.
#Obter o mesmo de forma programática
O payload do webhook e o GET /v3/session/{id}/decision/ trazem as três camadas num único objeto decision. Trata o webhook como a tua fonte de verdade e usa o polling apenas para reconciliação - alguns eventos, como edições de dados feitas por um revisor, só chegam por webhook. Consulta obter resultados com webhooks.
#Obter uma cópia para os teus registos
Para auditorias e submissões regulatórias, descarrega a sessão como PDF - reúne cada passo, os dados extraídos, as pontuações biométricas, os resultados de AML, e a decisão final. Consulta descarregar um relatório de verificação.