Regras de decisão e limiares
Toda verificação produz avisos, e você decide o que cada aviso faz - aprovar, revisar ou recusar. Esse mapeamento é onde o seu apetite ao risco realmente vive.
Cada etapa mapeia seus avisos para uma ação: aprovar, revisar ou recusar. Uma etapa configurada para recusar interrompe o fluxo de trabalho - as etapas seguintes nunca rodam, e você não é cobrado por elas. Isso faz da ordem das regras tanto uma decisão de risco quanto uma decisão de custo.
#Onde as decisões realmente são tomadas
É tentador pensar em um fluxo de trabalho como "as verificações que eu executo". As verificações são só metade disso. A outra metade - e a metade que determina sua taxa de aprovação - é o que os avisos de cada verificação estão configurados para fazer.
- Cada nó de recurso carrega seus próprios limiares e sua própria decisão.
- Uma verificação pode ser obrigatória ou opcional, o que já é, em si, uma decisão sobre quem passa.
- Uma regra alterada alcança novas sessões assim que o fluxo de trabalho é salvo.
Para cada etapa, cada aviso que ela pode gerar é mapeado para uma de três ações:
| Ação | Efeito |
|---|---|
| Approve (ou ignorar) | O aviso é registrado, mas não muda o resultado |
| Review | A sessão vai para In Review para uma pessoa decidir |
| Decline | A sessão é recusada e o fluxo de trabalho para |
Esse mapeamento é a sua política, expressa em configuração.
#Uma recusa interrompe o fluxo de trabalho
Esse é o comportamento que mais surpreende as pessoas, então vale a pena ser explícito: quando uma etapa recusa, a execução para ali. As etapas depois dela nunca rodam.
Duas consequências:
- O resultado vai ter verificações faltando que você esperava. Elas não falharam - simplesmente nunca foram executadas. Uma sessão recusada na verificação de ID não vai ter liveness, nem reconhecimento facial, nem AML.
- Você não é cobrado por elas. A cobrança é por recurso concluído, então uma etapa que nunca rodou não custa nada.
#Usando a ordem das regras para controlar custo
Como uma recusa interrompe o fluxo, a ordem das etapas é uma alavanca de gasto. Colocar uma verificação de risco barata na frente de um pacote caro faz com que o tráfego que nunca ia passar pare antes de você pagar pela parte cara.
Análise de dispositivo e IP a US$ 0,03 na frente de um fluxo completo de KYC é o exemplo padrão: filtra, de forma barata, o tráfego que você rejeitaria de qualquer forma.
O trade-off é a experiência do usuário e os falsos positivos. Os sinais de dispositivo e IP são as verificações mais ruidosas que a Didit oferece - redes corporativas, NAT de operadora e navegadores em nuvem colocam usuários legítimos atrás de endereços compartilhados. Bloquear um fluxo inteiro com base neles vai barrar clientes reais, então direcione-os para revisão em vez de recusa, a menos que você já tenha medido o seu próprio tráfego.
#Regras que exigem julgamento, não automação
Alguns avisos são inequívocos e devem recusar: um checksum de MRZ que falhou, um chip cuja assinatura não encadeia até o emissor, um rosto na sua blocklist. Essas são falhas de integridade.
Outros quase sempre funcionam melhor como revisão:
- Correspondências parciais de endereço no comprovante de endereço - os formatos variam por país.
- Correspondências parciais de nome na validação de banco de dados - fontes oficiais registram nomes de formas diferentes.
- Hits de baixa confiança em candidatos de AML - nomes comuns geram esses hits o tempo todo.
- Um reconhecimento facial no limite - veja pontuações e limiares de reconhecimento facial.
- Um sinal de rosto duplicado - que é fraude para uma conta nova e normal para um cliente recorrente.
E alguns são falhas de usabilidade que merecem uma nova tentativa, não um veredito: um chip NFC não lido, uma captura borrada, um frame de câmera perdido.
#Políticas de idade
Idade mínima e máxima são configuradas por fluxo de trabalho, e a ação em caso de violação é sua para escolher. MINIMUM_AGE_NOT_MET pode recusar diretamente, ou direcionar para revisão se a sua política permitir uma exceção com evidências. Ambas são legítimas; escolha de forma deliberada.
#Regras personalizadas sobre dados extraídos
Além do mapeamento por aviso, você pode escrever regras contra os dados que uma etapa extraiu - por exemplo, recusando quando um campo extraído assume um determinado valor. Duas coisas para ter em mente:
- A regra só pode agir sobre dados que a etapa realmente produziu. Se o OCR não extraiu o campo, a regra não tem nada para avaliar.
- Uma regra que recusa ainda interrompe o fluxo de trabalho, com as mesmas consequências descritas acima.
Se você está construindo uma regra que se baseia em uma característica protegida, trate isso como uma questão jurídica para o seu time de compliance antes de ser uma questão de engenharia.
#Teste as regras, não só as etapas
As etapas de um fluxo de trabalho são fáceis de verificar visualmente. As regras não são - a única forma de saber se um aviso é direcionado para onde você pensa é produzir aquele aviso.
O sandbox existe para isso. Cada cenário força um aviso específico, então você pode confirmar a ação de cada regra de ponta a ponta: decline_document_expired, review_face_match_borderline, decline_aml_hit, review_poa_partial_match, e assim por diante. Veja testes no sandbox.
Teste o caminho de revisão com o mesmo cuidado que o caminho de recusa. Uma regra que direciona para revisão só é útil se alguém realmente trabalhar a fila, e a forma de descobrir se o seu processo de revisão funciona é colocar uma sessão sintética por ele antes de um cliente real estar esperando.
#As mudanças se aplicam a novas sessões
Editar um fluxo de trabalho não muda retroativamente sessões já criadas. Uma sessão carrega a configuração com a qual foi criada, então, depois de uma mudança de regra, teste com uma sessão nova em vez de reverificar uma antiga.