Mudanças de regras sem surpresas

As regras raramente agem sozinhas. Uma nova regra de recusa tira pagamentos da regra de verificação adicional que antes cuidava deles, um limite mais baixo envia mais casos para a revisão manual e um modelo retreinado desloca as pontuações das quais todas as regras seguintes dependem. O efeito de uma mudança depende de todas as outras, de modo que uma alteração que parecia segura no papel pode se comportar de forma bem diferente em produção.

O custo também chega tarde. Um bom cliente que é recusado pode simplesmente ir embora sem reclamar. A fraude que passa aparece semanas ou meses depois, como chargebacks ou reclamações de golpes. Quando uma das duas fica visível, geralmente várias outras mudanças já entraram em produção, e a causa é difícil de rastrear.

Os valores em jogo são grandes dos dois lados. A UK Finance informa que, em 2025, seus membros evitaram £1,68 bilhão em fraudes não autorizadas, 70 pence para cada £1 tentado, enquanto os criminosos ainda roubaram £1,28 bilhão por meio de fraudes autorizadas e não autorizadas. Nessa escala, uma pequena perda de precisão movimenta dinheiro de verdade, para um lado ou para o outro.

A reexecução depende de um registro de cada decisão com as entradas exatamente como estavam naquele momento. Isso inclui as respostas de serviços externos, como uma verificação de dispositivo ou uma consulta a uma lista de vigilância, porque essas respostas mudam com o tempo e não podem ser buscadas de novo depois. Guardar a pontuação não basta. Ela mostra o que o sistema concluiu, mas não por quê, e não pode ser executada sob uma regra nova.

O mesmo registro atende às equipes de risco de modelos e de auditoria. A orientação revisada das agências bancárias dos Estados Unidos sobre gestão de risco de modelos, a SR 26-2 de abril de 2026, que substituiu a SR 11-7, trata a análise de resultados, que compara as saídas do modelo com os resultados reais por meio de monitoramento ou de backtesting, como parte de uma validação sólida. Ela também exclui de sua definição de modelo os processos determinísticos baseados em regras, de modo que as mudanças de regras podem ficar fora da validação formal. As equipes de fraude fazem bem em aplicar a mesma disciplina às próprias regras.

Execute a mudança proposta sobre um período de pagamentos passados, usando as entradas arquivadas, e compare as suas decisões com as que foram de fato tomadas. O resultado útil é o conjunto de decisões que se invertem: aprovações que agora seriam recusadas ou submetidas a verificação adicional e recusas que agora seriam aprovadas.

Detalhe as inversões por segmento de clientes, valor do pagamento, canal e comerciante. Depois, classifique cada pagamento invertido pelo que se sabe sobre ele: fraude confirmada, bom cliente confirmado ou ainda desconhecido. A fraude confirmada é o que a mudança ganha, e o bom cliente confirmado é o que ela custa. O grupo desconhecido exige cuidado, porque diminui à medida que os resultados chegam.

Uma mudança que não deveria alterar nada, como a reescrita de uma lógica existente, não deve produzir nenhuma inversão. Qualquer diferença que apareça é um defeito encontrado antes que os clientes se deparem com ele. Essa etapa é mais importante nos sistemas de pagamento instantâneo, como o Aani nos Emirados Árabes Unidos e o Pix no Brasil, em que o dinheiro sai em segundos e uma aprovação equivocada é difícil de desfazer.

Uma mudança pode parecer excelente no agregado enquanto os bons pagamentos que ela barra pertencem aos seus clientes mais valiosos ou a um comerciante que você não pode se dar ao luxo de incomodar. Tire uma amostra dos pagamentos invertidos e leia-os como um analista leria, começando pelos clientes de alto valor, pelos clientes antigos e pelos comerciantes-chave.

Para cada bloqueio, pergunte se a equipe saberia explicá-lo ao cliente em palavras simples. Os casos que surpreendem os revisores costumam apontar uma condição da regra mais ampla do que o pretendido, e é mais barato encontrá-los aqui do que na fila de reclamações.

A reexecução olha para o passado, e o comportamento muda. O passo seguinte é rodar a mudança proposta em modo sombra ao lado do tráfego real: ela vê cada pagamento e registra o que teria feito, enquanto as regras atuais continuam decidindo. Compare as suas decisões com as reais todos os dias e verifique se o padrão corresponde ao que a reexecução previu. Uma diferença entre os dois já é um achado em si.

Depois, libere em etapas, começando por uma pequena parcela do tráfego, um segmento ou um canal, com uma reversão que tenha sido testada. Registre quem aprovou a mudança, as evidências que viu e o motivo. Esse registro é o que um auditor vai pedir e o que a sua própria equipe vai precisar quando um resultado parecer estranho meses depois.

Algumas mudanças são dados, e não lógica. Incluir uma conta em uma lista de contas laranja conhecidas, ou retirá-la depois de uma reclamação, deve ter efeito em instantes e ser reversível na hora, com um registro de quem a fez. Uma regra nova, um limite novo ou um modelo retreinado passam por reexecução, modo sombra e aprovação. Combine de antemão quais mudanças seguem cada caminho, para que uma edição urgente de lista nunca seja atrasada e uma mudança de lógica nunca pule a revisão.

Acompanhe estes indicadores antes e depois de cada mudança, por segmento, e releia os números de fraude quando os resultados tiverem amadurecido.

Taxa de aprovação

Parcela dos pagamentos aprovados, por segmento e canal

Fraude capturada e não capturada

Em valor e em quantidade

Taxa de verificação adicional

Com que frequência se exige verificação adicional dos clientes e quantos a concluem

Volume de revisão

Casos enviados aos analistas e o tempo que levam

Contatos de clientes

Ligações e reclamações sobre pagamentos recusados ou retidos

O Mantika Argus guarda cada decisão exatamente como foi tomada, para que uma regra nova rode sobre os seus pagamentos passados e depois em modo sombra antes de entrar em produção.