Nem todas as aprovações são iguais: utilizando níveis de garantia nas decisões de cadastro e verificação de clientes.

Considere as três passagens como três níveis diferentes de evidência e decida antes do lançamento o que cada uma delas tem permissão para fazer.chipA aprovação depende dos dados assinados pelo estado emissor.gov_dbA aprovação depende do próprio histórico do governo.documentA aprovação depende da aparência do documento em uma fotografia. Os três podem ser clientes legítimos e todos devem ser cadastrados, mas não devem ter os mesmos limites por padrão.

A regra prática é: direcione a solicitação com base no nível de garantia, juntamente com a foto com a qual o rosto foi comparado, defina uma política explícita para cada nível e ofereça aos clientes uma maneira de subir de nível em vez de reprová-los.

O que significa cada nível de garantia?

Em Toden Verificação de identidade : cada verificação bem-sucedida acarreta umassuranceLevel, conforme descrito na documentação sobre Países e Tipos de Identificação (abre num novo separador) :

A ordem reflete a origem das evidências. NIST A diretriz de comprovação de identidade da [empresa/organização], SP 800-63A-4 (abre num novo separador) (julho de 2025), usa uma hierarquia semelhante: sua categoria de evidência mais forte exige validação "por meio da verificação criptográfica do conteúdo da evidência e da fonte emissora", incluindo "uma cadeia de confiança que remonta a uma âncora de confiança". É isso que uma verificação de chip faz. NIST É uma estrutura dos EUA e suas categorias não correspondem diretamente a esses níveis, mas a lógica é a mesma.

Por que o passe não é suficiente para rotear?

Porque duas verificações com o mesmo veredicto podem apresentar níveis de prova muito diferentes.

Considere dois candidatos hipotéticos para o mesmo aplicativo de investimento. Um é um cliente queniano verificado por meio de registros governamentais, com uma selfie que corresponde à foto registrada. O outro é um candidato de um país sem banco de dados acessível, verificado por meio de uma foto da carteira de habilitação, com a selfie correspondendo à foto impressa na carteira. Ambos foram considerados verificados. Apenas um deles foi verificado por meio de uma fonte que o candidato não poderia ter fornecido.

O segundo campo que importa éfacialMatchSource, que indica com qual foto a selfie foi comparada:gov_record,chipoudocumentUma correspondência com a foto impressa é uma evidência mais fraca, porque o falsificador imprime seu próprio rosto na falsificação; Toden Isso nunca aumenta o nível de garantia. Uma política que analisaassuranceLevelmas ignorafacialMatchSourceNão vê metade da história.

Como cada nível deve ser tratado?

Aqui está uma política inicial para um aplicativo que armazena e movimenta dinheiro. Ela é meramente ilustrativa; seus próprios limites dependem do seu produto, da sua licença e da sua tolerância ao risco.

Três princípios norteiam a situação.

1. O nível define o teto, não o chão. UmdocumentUm cliente de nível inferior não é um suspeito. É um cliente sobre o qual você sabe menos, o que justifica limites menores, e não a rejeição do pedido.

2. A segurança diz respeito à identidade, não ao risco .chipO passaporte apenas confirma que a pessoa é quem consta nele. Não informa nada sobre se ela está sob sanções, se é politicamente exposta ou se está prestes a cometer fraude. A triagem e o monitoramento são aplicados em todos os níveis.

3. Deixe os clientes subirem. Um cliente emdocumentUsuários que posteriormente comprovarem a identidade com um passaporte com chip no aplicativo móvel ou com um segundo documento de identificação devem ter a oportunidade de subir de nível. Ofereça a possibilidade de upgrade em vez de impor um limite permanente.

Como isso se parece em um gráfico de decisão?

Em Toden Os fluxos de trabalho , um gráfico de decisão executado após a conclusão das verificações, ramificam-se em campos como:verification.assuranceLeveleverification.facialMatchSourcee aterrissa em aprovar, revisar ou rejeitar. Uma ação de tag pode marcar o nível para que seu backend defina limites a partir doworkflow.run.completedWebhook. Um gráfico ilustrativo para a política acima:

1. Wait for screening
2. If screening.anyMatch            -> open case, then REVIEW
3. If verification.status != VERIFIED -> DECLINE
4. If assuranceLevel in [chip, gov_db]
     and facialMatchSource in [chip, gov_record] -> tag "tier-full", APPROVE
5. If assuranceLevel == document    -> tag "tier-reduced", APPROVE
6. Otherwise                        -> REVIEW

Seu backend lê o resultado e as tags do webhook e aplica os limites. Como cada execução é vinculada à versão do fluxo de trabalho com a qual foi iniciada, alterar a política posteriormente nunca reescreve uma decisão já tomada. A documentação de tomada de decisão (abre num novo separador) lista os campos e os tipos de nó.

Quais são os casos extremos?

Um chip no caminho do banco de dados do governo. Em Toden Quando um documento de identidade também é verificado em um banco de dados governamental (um passaporte nigeriano, por exemplo), a selfie é comparada com a foto do governo em vez da foto do chip. Nesse processo, um chip chega aochipsomente se a Autenticação Ativa provar que não é uma cópia; caso contrário, a verificação ainda será aprovada.gov_dbIsso não representa, na prática, uma piora: ambos os níveis recebem o mesmo tratamento na política acima.

Um chip que não pôde ser confirmado. Um chip cujo país emissor não está na lista de certificados confiáveis, ou que não pode ser lido, nunca falha na verificação. Ele simplesmente não contribui para a garantia do chip, e a verificação é decidida com base em suas outras verificações. Veja o NFC Consulte a documentação do chip (abre num novo separador) para obter mais detalhes.

Aprovações mesmo com verificação reprovada. Níveis de garantia estão associados à aprovação nas verificações. Quando um revisor aprova alguém cuja verificação foi reprovada, o registro mantém a informação de reprovação.checkStatuse seureasonCodeTrate essas aprovações como uma categoria própria em sua política de limites, e não como uma aprovação em qualquer nível.

Lista de verificação antes do lançamento

• LojaassuranceLevelefacialMatchSourceCom cada registro de cliente, ao lado do resultado.

• Redija uma política de uma página que associe cada combinação a um resultado e um limite.

• Implemente-o como um grafo de decisão para que seja aplicado de forma consistente e marque a camada correspondente ao seu backend.

• Ofereça aos clientes de nível inferior uma rota para um nível superior.

• Mantenha a triagem e o monitoramento ativados em todos os níveis.

• Analise a política ao adicionar novos mercados, pois o nível que seus novos clientes podem alcançar depende do país.

Os requisitos de diligência prévia do cliente variam conforme a jurisdição e a licença, e este artigo fornece informações gerais, não constituindo aconselhamento jurídico. A ideia central é a seguinte: saiba o quão robustamente cada identidade foi comprovada e deixe que isso determine o quanto você deve confiar nela.