Monitorar uma integração de KYC, as métricas que de fato importam

Integrar uma verificação de identidade é a parte fácil. Mantê-la saudável em produção, sabendo a qualquer momento se ela está aprovando bem, rejeitando o que deve e respondendo rápido, é o trabalho de verdade, e é o que separa uma integração que envelhece bem de uma que degrada em silêncio até alguém reclamar da conversão. O problema é que a maioria dos painéis mede a coisa errada: contam quantas verificações rodaram, não o que elas significaram para o negócio.

Este artigo propõe um conjunto pequeno de métricas que realmente importam para uma integração de KYC, e um método para lê-las. A pergunta que o painel precisa responder não é quantas verificações aconteceram, e sim: está tudo funcionando como deveria, e se não está, o que quebrou, a experiência do usuário legítimo ou a defesa contra fraude?

Comece pelo método: indicador e objetivo

Antes das métricas, o método. A engenharia de confiabilidade do Google, no livro Site Reliability Engineering, dedica um capítulo aos service level objectives, os SLOs, e a distinção que ele faz vale para qualquer integração. Um indicador de nível de serviço, o SLI, é uma medida quantitativa de algum aspecto do serviço, como a latência de uma requisição. Um objetivo de nível de serviço, o SLO, é a meta que se define sobre esse indicador, como noventa e cinco por cento das verificações concluídas abaixo de um certo tempo.

A lição prática desse capítulo é medir a distribuição, não a média. A média esconde o cliente que esperou muito; o percentil o revela. Por isso a latência que importa não é a média, é o p95 ou o p99, o tempo abaixo do qual ficam 95 ou 99 por cento das verificações. Um p95 alto significa que uma parcela real de usuários está esperando demais, ainda que a média pareça boa.

As quatro taxas de decisão

O coração do painel de KYC são as taxas de resultado da decisão, e elas só fazem sentido lidas juntas. São quatro:

• Taxa de aprovação: proporção de verificações que a decisão aprovou. Sozinha não diz nada, uma aprovação de cem por cento pode ser um sistema que não filtra nada.
• Taxa de revisão manual: proporção que caiu na fila de análise humana. É a métrica de custo operacional mais direta, porque cada revisão consome tempo de gente.
• Taxa de rejeição: proporção reprovada. Uma alta súbita aqui é ambígua, e é justamente essa ambiguidade que o resto do painel precisa desfazer.
• Taxa de recaptura: proporção que precisou refazer uma etapa, tirar a foto de novo, repetir a prova de vida. Ela mede fricção técnica, não fraude.

A leitura conjunta é o que dá diagnóstico. Uma rejeição que sobe junto com a recaptura aponta problema de captura ou de qualidade de imagem, não onda de fraude. Uma rejeição que sobe sem a recaptura acompanhar, e com sinais de risco subindo junto, é outra história.

Distinguir queda de conversão de aumento de fraude

Esse é o julgamento mais valioso que um painel de KYC habilita, e o mais fácil de errar. Rejeição alta pode ser sinal de que a defesa está funcionando contra um ataque real, ou de que o sistema começou a barrar gente boa por engano. As duas situações pedem reações opostas, afrouxar num caso seria abrir a porta, apertar no outro afogaria a conversão.

O que separa uma da outra é olhar as métricas certas ao lado da rejeição. Se a rejeição sobe acompanhada de indicadores de risco, muitos cadastros do mesmo aparelho, padrões de automação, atributos compartilhados, é provável que seja ataque, e a defesa está fazendo o trabalho dela. Se a rejeição sobe com a recaptura e sem sinal de risco, é fricção, e o custo aparece como falso positivo, o cliente legítimo rejeitado que some da conversão sem aparecer em nenhum relatório de fraude. Um painel que só mostra a taxa de rejeição não permite essa distinção; um que mostra rejeição, recaptura e sinais de risco lado a lado, permite.

Latência, com um motivo regulatório

Latência não é só experiência. Para quem opera sob regulação de prevenção à lavagem de dinheiro, o tempo de resposta se conecta a obrigação. A Circular BCB 3.978/2020, do Banco Central, estabelece prazos para a seleção e a análise das operações e situações que merecem atenção, e uma etapa automatizada lenta come o orçamento de tempo que a instituição tem para cumprir esse dever. Medir latência, aqui, é medir margem regulatória, não só conforto do usuário.

E há a distinção técnica que muda o que se mede: verificação síncrona versus assíncrona. Na etapa síncrona, a latência é sentida pelo usuário na tela, e o p95 governa a experiência. Na assíncrona, o que importa é o tempo até a decisão final chegar por webhook, e o SLO se define sobre esse tempo de ponta a ponta, não sobre a resposta imediata da API.

O erro de fonte externa, a métrica que quase ninguém tem

Toda verificação depende de fontes que não estão sob seu controle: a consulta cadastral, a base oficial, o serviço de análise. Essas fontes falham, ficam lentas, ou devolvem indisponível, e quando falham a sua verificação não pode simplesmente travar. A taxa de erro e a latência de cada fonte externa precisam estar no painel, separadas da taxa de decisão, porque uma degradação da fonte pode se disfarçar de aumento de rejeição se ninguém a estiver medindo à parte.

Vale lembrar a distinção de projeto que já tratamos: fonte indisponível não é o mesmo que dado inexistente, e tratar as duas como a mesma coisa produz decisão errada. O painel deve deixar visível quando uma fonte está degradada, para que a operação saiba que a queda de qualidade veio de fora, não do próprio fluxo.

O que o produto precisa expor para isso funcionar

Nada desse painel é possível se a plataforma de verificação não expõe os sinais certos. Três capacidades são o mínimo. Primeiro, uma decisão versionada: saber qual versão do modelo ou da calibração tomou cada decisão é o que permite atribuir uma mudança de comportamento a uma mudança de configuração, e não a um fantasma. Segundo, um webhook canônico e confiável, porque é por ele que o resultado assíncrono chega e é dele que a métrica de tempo até a decisão se alimenta. Terceiro, um fluxo de eventos ao vivo para o painel operacional acompanhar o que está acontecendo agora, não só o que aconteceu ontem.

Na UNIFOKAL, por exemplo, o dashboard recebe os eventos por um canal ao vivo, o webhook é o registro canônico da decisão para o sistema do cliente, e cada decisão carrega a versão do modelo que a produziu. Não é o painel pronto, é a matéria-prima dele: os sinais que permitem à equipe construir seus próprios SLIs e SLOs e responder, a qualquer hora, à única pergunta que interessa, está funcionando como deveria. Um score de risco explicável fecha o ciclo, porque quando o painel aponta uma anomalia, a decisão precisa ser legível o bastante para explicar o porquê.

Fontes citadas

• Google, Site Reliability Engineering, capítulo Service Level Objectives, sobre SLI, SLO e medição por percentil: sre.google
• ISO/IEC 19795-1, Biometric performance testing and reporting, sobre as métricas de erro e de falha de aquisição em sistemas biométricos, base para as taxas de rejeição e de recaptura
• Circular BCB 3.978/2020, do Banco Central do Brasil, sobre os prazos de seleção e análise de operações no âmbito da prevenção à lavagem de dinheiro