O que um curso de iGaming me ensinou sobre sistemas anti-fraude

Fiz o curso Anti-Fraud and Payments Handling da iGaming Academy esperando uma lista de regras para bloquear transações ruins. O que ele de fato me ensinou foi que anti-fraude é principalmente uma série de julgamentos, e quase nenhum deles tem uma resposta certa e limpa.

Prevenção de fraude é um trade-off, não um filtro

O instinto é pensar em fraud detection como um filtro: transações ruins de um lado, boas do outro. Sistemas reais não funcionam assim, porque as regras que pegam mais fraude também pegam clientes de verdade, e todo cliente legítimo que você bloqueia é receita perdida mais uma pessoa que provavelmente não volta.

Então a pergunta nunca é "essa regra pega fraude." É "quanto essa regra custa quando está errada, e com que frequência ela vai estar errada." Uma regra que pega 90% da fraude mas rejeita 5% dos clientes genuínos pode facilmente ser pior para um negócio do que uma regra que pega 60% e não rejeita quase ninguém.

Nem toda decline significa a mesma coisa

Essa foi a distinção mais útil do curso, de longe. Uma transação declined pode significar saldo insuficiente, um timeout de rede, um cartão reportado como roubado, ou um banco bloqueando uma transação que achou suspeita. Esses são sinais completamente diferentes que acontecem de chegar pelo mesmo canal.

Saldo insuficiente é uma condição temporária, então tentar de novo depois ou por outra rota é razoável. Um cartão reportado como roubado é uma resposta permanente e definitiva, e tentar de novo em outro lugar é tentar empurrar uma transação fraudulenta através de um acquirer que ainda não pegou isso. Tratar essas duas respostas de forma idêntica é como um sistema de pagamento acaba ou perdendo vendas legítimas ou lavando fraude.

Padrões importam mais do que transações individuais

Uma única transação geralmente não conta muito sozinha. Um pagamento de €50 não chama atenção. O mesmo cartão produzindo tentativas recusadas repetidas numa janela curta é uma história completamente diferente, porque é assim que card testing se parece: alguém com uma lista de cartões roubados checando quais ainda estão ativos antes de gastar eles.

Isso mudou como eu penso sobre os dados que um sistema de pagamento precisa armazenar. Regras que só veem a transação atual não conseguem detectar um padrão, então o histórico precisa estar lá e precisa ser consultável no momento da decisão, não só arquivado para relatórios depois.

Evidência é parte do produto

A parte em que eu não tinha pensado nem um pouco antes do curso: quando um acquirer ou um regulador pergunta por que uma transação foi aprovada ou recusada, "o sistema decidiu" não é uma resposta. Você precisa do registro do que foi checado, qual foi o resultado, e qual regra disparou.

Isso remodelou persistence para mim. Na maioria dos projetos o database é onde o estado vive. Em pagamentos ele também é a trilha de auditoria, e deletar um registro de pagamento não é limpeza, é destruir evidência.

Dados de cartão têm regras próprias

Armazenar números completos de cartão não é uma decisão para tomar de ânimo leve, é uma obrigação de compliance com requisitos reais atrelados. A versão prática para um projeto como o meu é direta: guarde o BIN e os últimos quatro dígitos, o que basta para identificar um cartão entre transações e mostrar a um cliente qual cartão ele usou, e nunca armazene o resto.

O que eu de fato tirei disso

O curso mudou o que eu acho que um sistema de fraude é. Não é um muro que você põe na frente dos pagamentos. É um conjunto de decisões sobre risco aceitável, tomadas com informação incompleta, onde ser agressivo demais custa dinheiro de verdade e ser permissivo demais custa mais ainda. Construir o PayMaestro depois foi principalmente um exercício em transformar esses julgamentos em código que de fato pudesse ser inspecionado e explicado depois.