SQL patterns I use to catch transaction fraud

Padrões de SQL que uso para detectar fraudes em transações

Em um mundo onde as transações financeiras acontecem em milissegundos, a detecção de fraudes se tornou uma das maiores dores de cabeça para empresas de tecnologia e comércio eletrônico no Brasil. Recentemente, uma discussão acalorada no Hacker News, iniciada pelo usuário redbell, trouxe à tona uma abordagem que muitos empresários brasileiros podem estar negligenciando: o uso inteligente de padrões SQL para identificar comportamentos suspeitos antes que o prejuízo aconteça.

Diferente de soluções complexas de machine learning ou sistemas de terceiros caros, redbell compartilhou uma série de consultas SQL que qualquer equipe de dados pode implementar rapidamente. A ideia é simples: usar a própria base de dados transacional para buscar sinais de fraude, como múltiplas tentativas de pagamento em segundos, alterações de IP em zonas geográficas improváveis e padrões de uso de cartões que destoam do histórico do cliente.

Por que SQL ainda é relevante para detectar fraudes?

Muita gente acredita que, para combater fraudes, é preciso investir em inteligência artificial ou APIs de risco. Mas a verdade é que grande parte dos golpes segue padrões previsíveis. Segundo redbell, mais de 60% das fraudes em transações podem ser identificadas com consultas SQL bem escritas, especialmente quando combinadas com dados de sessão e logs de acesso.

O brasileiro, que lida com altas taxas de chargeback e fraudes em cartão de crédito, pode se beneficiar enormemente dessa abordagem. Empresas de varejo online, fintechs e até marketplaces podem configurar alertas simples que disparam quando uma consulta SQL encontra um padrão suspeito.

Os padrões SQL que mais funcionam

Redbell listou alguns padrões que considera essenciais. Vou traduzir e adaptar para a realidade do empresário brasileiro:

• Múltiplas tentativas em curto intervalo: Consultas que contam transações no mesmo cartão ou CPF em menos de 10 segundos. Um sinal clássico de ataque automatizado.
• Mudança abrupta de geolocalização: Comparar o IP da transação atual com o histórico do cliente. Se ele estava em São Paulo e, em 5 minutos, aparece uma compra de Manaus, há algo errado.
• Cartões novos com valores altos: Clientes recém-cadastrados que imediatamente tentam compras de alto valor são suspeitos. Uma consulta que filtra por data de cadastro e valor da transação ajuda a identificar.
• Falha no CVV repetida: Mais de 3 tentativas com CVV inválido no mesmo cartão em menos de 1 hora é um forte indicador de fraude.

Esses padrões podem ser implementados com SQL simples, usando janelas de tempo (window functions) e agregações. O segredo está em ter os logs de transação bem estruturados e com timestamps precisos.

Como implementar na prática?

Não é necessário ter um data lake gigante. Muitas empresas brasileiras usam bancos relacionais como PostgreSQL, MySQL ou SQL Server. Redbell sugere criar views ou tabelas temporárias que alimentem dashboards de risco. O importante é que as consultas sejam rápidas, pois a decisão de aprovar ou bloquear uma transação deve ser em tempo real.

Por exemplo, uma consulta pode olhar para os últimos 5 minutos de transações de um determinado usuário e contar quantas vezes ele tentou usar cartões diferentes. Se passar de 3, o sistema pode automaticamente colocar a transação em análise manual.

Outro padrão útil é a detecção de "clusters de fraude": quando um mesmo IP ou dispositivo faz múltiplas transações com nomes de titulares diferentes. Isso é comum em golpes de "teste de cartão", onde criminosos verificam se cartões roubados funcionam antes de usá-los em compras maiores.

Cuidados com falsos positivos

É claro que nem todo padrão diferente é fraude. Clientes legítimos podem viajar, mudar de dispositivo ou tentar um cartão alternativo por razões válidas. Redbell alerta para o equilíbrio: as consultas SQL devem ser ajustadas com limites de tempo e valor, e sempre combinadas com uma segunda camada de verificação, como SMS ou biometria.

No contexto brasileiro, onde o Pix e os cartões de crédito dominam, os padrões de fraude mudam. As consultas devem considerar a granularidade dos dados, como o hash do dispositivo e o user-agent do navegador. Quanto mais colunas de contexto você tiver na tabela de transações, mais precisas serão as consultas.

O futuro é acessível

A grande lição da história de redbell é que, muitas vezes, a solução para problemas complexos está nas ferramentas que já temos. SQL é uma tecnologia madura, barata e que não exige times enormes de ciência de dados. Para o empresário brasileiro, que muitas vezes opera com margens apertadas, essa pode ser a diferença entre um chargeback e uma transação segura.

Comece hoje: pegue seu banco de transações, identifique os campos de timestamp, valor, cartão, IP e dispositivo. Escreva uma consulta que conte tentativas no último minuto. Depois, expanda para padrões geográficos e de comportamento. Em uma semana, você terá um sistema de detecção de fraudes funcional, sem depender de soluções externas caras.

A fraude não espera o crescimento da empresa. Ela ataca desde o primeiro dia. E com SQL, você pode se antecipar a ela.