Regras de decisão e limiares
Cada comprovação produz avisos, e tu decides o que cada aviso faz - passar, rever, ou recusar. Esse mapeamento é onde o teu apetite de risco realmente vive.
Cada passo mapeia os seus avisos para uma ação: passar, rever, ou recusar. Um passo configurado para recusar para o fluxo de trabalho - os passos seguintes nunca correm, e não és faturado por eles. Isso torna a ordem das regras tanto uma decisão de risco como uma decisão de custo.
#Onde as decisões são realmente tomadas
É tentador pensar num fluxo de trabalho como "as comprovações que executo". As comprovações são apenas metade disso. A outra metade - e a metade que determina a tua taxa de aprovação - é o que os avisos de cada comprovação estão configurados para fazer.
- Cada nó de funcionalidade tem os seus próprios limiares e a sua própria decisão.
- Uma comprovação pode ser obrigatória ou opcional, o que já é em si uma decisão sobre quem passa.
- Uma regra alterada chega às sessões novas assim que o fluxo de trabalho é guardado.
Para cada passo, cada aviso que pode levantar mapeia para uma de três ações:
| Ação | Efeito |
|---|---|
| Approve (ou ignorar) | O aviso é registado 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 tua política, expressa em configuração.
#Uma recusa para o fluxo de trabalho
Este é o comportamento que mais surpreende as pessoas, por isso vale a pena ser explícito: quando um passo recusa, a execução para ali. Os passos a seguir nunca correm.
Duas consequências:
- O resultado vai ter comprovações em falta que esperavas. Não falharam - nunca foram executadas. Uma sessão recusada na verificação de ID não vai ter prova de vida, nem correspondência facial, nem AML.
- Não és faturado por elas. A faturação é por funcionalidade concluída, por isso um passo que nunca correu não custa nada.
#Usar a ordem das regras para controlar o custo
Como uma recusa para o fluxo, a ordem dos passos é uma alavanca de custo. Colocar uma comprovação de risco barata à frente de um pacote caro significa que o tráfego que nunca ia passar para antes de pagares pela parte cara.
Análise de dispositivo e IP a 0,03 $ à frente de um fluxo KYC completo é o exemplo padrão: filtra, de forma barata, o tráfego que rejeitarias de qualquer forma.
O compromisso é a experiência do utilizador e os falsos positivos. Os sinais de dispositivo e IP são as comprovações mais ruidosas que a Didit oferece - redes empresariais, NAT de operadora, e navegadores na cloud colocam utilizadores genuínos atrás de endereços partilhados. Filtrar um fluxo inteiro com base neles vai bloquear clientes reais, por isso encaminha-os para review em vez de recusar, a menos que já tenhas medido o teu próprio tráfego.
#Regras que precisam de julgamento, não de automação
Alguns avisos são inequívocos e devem recusar: uma checksum de MRZ falhada, um chip cuja assinatura não encadeia até ao seu emissor, uma face na tua lista de bloqueio. São falhas de integridade.
Outros são quase sempre melhor como revisão:
- Correspondências parciais de morada no comprovativo de morada - os formatos variam por país.
- Correspondências parciais de nome na validação de base de dados - as fontes oficiais registam nomes de forma diferente.
- Ocorrências de candidato AML com baixa confiança - nomes comuns geram-nas constantemente.
- Uma correspondência facial no limite - consulta pontuações e limiares de correspondência facial.
- Uma sinalização de face duplicada - que é fraude para uma conta nova e normal para um cliente que regressa.
E alguns são falhas de usabilidade que merecem uma repetição, não um veredito: um chip NFC não lido, uma captura desfocada, uma imagem de câmara perdida.
#Políticas de idade
A idade mínima e máxima são configuradas por fluxo de trabalho, e a ação sobre uma violação é escolha tua. MINIMUM_AGE_NOT_MET pode recusar diretamente, ou encaminhar para revisão se a tua política permitir uma exceção com prova. Ambas são legítimas; escolhe deliberadamente.
#Regras personalizadas sobre dados extraídos
Para além do mapeamento por aviso, podes escrever regras sobre os dados que um passo extraiu - por exemplo, recusando quando um campo extraído assume um valor específico. Duas coisas a ter em conta:
- A regra só pode atuar sobre dados que o passo realmente produziu. Se o OCR não extraiu o campo, a regra não tem nada para avaliar.
- Uma regra que recusa continua a parar o fluxo de trabalho, com as mesmas consequências descritas acima.
Se estiveres a construir uma regra que ativa com base numa característica protegida, trata isso como uma questão jurídica para a tua equipa de compliance antes de ser uma questão de engenharia.
#Testa as regras, não só os passos
Os passos de um fluxo de trabalho são fáceis de verificar a olho. As regras não são - a única forma de saber que um aviso é encaminhado para onde pensas é produzir esse aviso.
O sandbox existe para isto. Cada cenário força um aviso específico, por isso consegues 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 por aí adiante. Consulta testar em sandbox.
Testa o caminho de revisão com tanto cuidado como o caminho de recusa. Uma regra que encaminha para revisão só é útil se alguém trabalhar mesmo a fila, e a forma de descobrir se o teu processo de revisão funciona é fazer passar uma sessão sintética por ele antes de um cliente real estar à espera.
#As alterações aplicam-se a sessões novas
Editar um fluxo de trabalho não muda retroativamente as sessões já criadas. Uma sessão transporta a configuração com que foi criada, por isso, depois de uma alteração de regra, testa com uma sessão nova em vez de voltares a verificar uma antiga.