Padrões SQL usados para detectar fraudes em transações

(analytics.fixelsmith.com)

17 pontos por GN⁺ 2026-05-17 | 4 comentários | Compartilhar no WhatsApp

Na detecção de fraudes, muitas vezes o ponto de partida vem antes do machine learning: acertar tabelas e joins e usar SQL para encontrar padrões anômalos de velocidade, localização, valor, comerciante e faixa horária
Velocity encontra períodos em que transações do mesmo titular do cartão se concentram em pouco tempo, exigindo ajuste de janela temporal, limiares e whitelist para falsos positivos
Impossible travel usa LAG() e cálculo de distância para sinalizar, como forte indício de cartão clonado, casos fisicamente impossíveis como um pagamento em Chicago seguido 7 minutos depois por outro em Los Angeles
Anomalias de valor procuram faixas como $1.00, $99.99 e $499.99, que podem indicar teste de cartão ou tentativa de contornar regras, mas não funcionam tão bem para transações de benefícios
Combinando pico por comerciante, transações fora do horário habitual e colunas derivadas com funções de janela, é possível pontuar transações por múltiplos sinais e reduzir o ciclo de iteração de semanas para horas

Padrões SQL para encontrar sinais de fraude em dados transacionais

A detecção de fraudes muitas vezes começa, antes de machine learning ou bancos de dados em grafo, com as tabelas e joins corretos e SQL para encontrar comportamentos estranhos nas transações
Pode ser aplicada a dados em que dinheiro se move e logs são deixados, como cartão de crédito, cobranças médicas, e-commerce, POS e programas governamentais de benefícios
Em um novo dataset, normalmente os padrões são acumulados nesta ordem: velocidade, deslocamento impossível, anomalias de valor, concentração por comerciante, horários anormais e sinais baseados em funções de janela

1. Velocity: transações excessivas em pouco tempo

Quando alguém tenta esgotar rapidamente um cartão ou conta roubada, aparece um padrão de concentração de transações em curto intervalo para o mesmo titular do cartão
A query básica agrupa as transações dos últimos 30 dias por hora e encontra períodos em que a contagem por cardholder_id ultrapassa um limite
Os principais parâmetros de ajuste são o tamanho da janela de tempo e o limiar de quantidade de transações
- É possível rodar em paralelo versões de 1 minuto, 5 minutos e 1 hora para comparar
- Grupos de teste de cartão podem concentrar transações em segundos, enquanto grupos de fraude em benefícios podem agir ao longo de meio dia, então a escala muda
Usuários legítimos também podem ultrapassar o limite
- Operadores que administram máquinas de venda automática
- Pessoas que recarregam cartões pré-pagos em massa
- Depois da exploração inicial, é preciso manter uma whitelist de alvos de falso positivo
A abordagem com janela deslizante calcula a quantidade de transações nos últimos 5 minutos com COUNT(*) OVER (...) RANGE BETWEEN INTERVAL '5 minutes' PRECEDING AND CURRENT ROW
QUALIFY funciona em Snowflake, BigQuery, Databricks e Teradata
- No Postgres, é preciso envolver a query inteira em uma CTE e filtrar do lado de fora

2. Impossible travel: deslocamento fisicamente impossível

Se um cartão é usado em Chicago e 7 minutos depois em Los Angeles, há grande chance de que uma das transações seja falsa
Esse padrão é um forte sinal para detectar cartões clonados, já que quase não há motivo legítimo para um mesmo cartão estar em dois lugares distantes em questão de minutos
A query usa LAG() para trazer o horário e a localização da transação anterior e calcula a distância e o tempo entre a posição anterior e a atual
haversine é uma função para calcular a distância de grande círculo (great-circle distance)
- A maioria dos data warehouses oferece isso
- Se não houver, é uma função simples o bastante para implementar manualmente
O limiar de exemplo é 600mph
- Como a velocidade de cruzeiro de um jato comercial é cerca de 575mph, isso significa uma velocidade inviável até mesmo de avião
- Se baixar para 100mph, dá para capturar deslocamentos terrestres rápidos, mas começam a aparecer também viagens legítimas, como pessoas voando de verdade ou pais levando filhos
Há sinais adicionais na mesma família
- Transações em duas cidades distantes do mesmo estado em 5 minutos podem sugerir uma quadrilha regional de clonagem
- Transações em vários ZIP codes em uma hora podem sugerir uma quadrilha de skimming atuando em uma região
- Transações cruzando fronteiras em 10 minutos podem ser sinal de uma quadrilha internacional

3. Amount anomalies: transações suspeitas em certas faixas de valor

Em fraudes, há padrões de valor que aparecem com frequência, mas são raros em uso normal
As condições de exemplo procuram as seguintes faixas
- $1.00, $5.00, $10.00
- De $99.50 até abaixo de $100.00
- De $499.50 até abaixo de $500.00
Valores pequenos em dólares inteiros costumam ser um sinal de teste de cartão
- O fluxo típico é verificar se números obtidos em dumps de cartões realmente funcionam antes de revendê-los
- É raro que o titular real compre exatamente algo de $1.00
- Um café tende a custar $4.73 e combustível $52.81, não valores exatamente arredondados
Valores logo abaixo de um limite têm outro significado
- $99.99 pode ser uma tentativa de evitar a faixa em que muitos lugares passam a exigir documento a partir de $100
- $499.99 pode ser uma tentativa de contornar um limite diário de ATM de $500
- Isso indica que quem transaciona conhece a regra e está ficando logo abaixo dela
Em transações de benefícios, padrões de valores arredondados não ajudam tanto
- Benefícios não costumam ser testados da mesma forma que cartões
- Em geral, beneficiários duplicados são um sinal mais importante

4. Suspicious merchants: concentração anormal por comerciante

Se um leitor de cartão em uma bomba de combustível é infectado por um skimmer, isso pode gerar não uma fraude isolada, mas dezenas de fraudes
Todos os cartões usados naquele leitor ao longo de semanas podem acabar no banco de dados de alguém
Pela ótica do comerciante, isso aparece como um aumento, em curto período, no número de cartões não relacionados entre si, junto com valores transacionados maiores
Um exemplo simples de critério agrupa os últimos 7 dias por comerciante e por hora para calcular
- Número de cartões únicos
- Total de transações
- Valor total transacionado
- E procura horas em que o número de cartões únicos passa de 20 e o total supera $5000
Limiares estáticos têm problema de ajuste por porte
- A Costco pode ultrapassar isso em 90 segundos
- Uma livraria de usados talvez quase nunca ultrapasse
Uma forma melhor é comparar cada comerciante com sua própria linha de base histórica
- Agrupar os últimos 60 dias por hora
- Calcular a média histórica de cartões únicos para cada comerciante com base nos 168 buckets horários anteriores
- Encontrar períodos em que a contagem atual de cartões únicos ultrapassa 3 vezes a média histórica
Os 168 buckets horários representam as últimas 7 janelas horárias por dia ao longo de 7 dias
- Porque sazonalidade diária e semanal importa
- A mesma cafeteria tem linhas de base diferentes para terça às 14h e sábado às 9h
Como ponto de partida, dá para usar 3 vezes o normal
- É folgado o suficiente para não gerar um excesso de alertas
- E ainda rígido o suficiente para capturar janelas realmente estranhas

5. Off-hours: transações fora do horário habitual da pessoa

A maioria das pessoas tem hábitos de gasto
Se alguém que normalmente vive entre 9h e 17h começa de repente a abastecer às 3h da manhã, pode ser sinal de uso por outra pessoa ou de viagem
Se está viajando ou não, isso pode ser validado com outros sinais
A query calcula, para os últimos 90 dias, a contagem de transações por titular do cartão e por hora, e só considera como faixa horária habitual as horas em que houve pelo menos 2 transações
Depois, sinaliza se o horário de uma nova transação cai fora do intervalo entre earliest_hour e latest_hour daquele titular
A condição interna de “pelo menos 2 transações naquela hora” é importante
- Evita que um abastecimento noturno isolado de 3 meses atrás entre na faixa habitual
- Ajusta o critério para refletir hábito real, e não apenas “algo que aconteceu uma vez”
A desvantagem é que isso exige dados históricos
- Contas novas não têm linha de base
- Para contas novas, é possível usar padrões gerais de horário do conjunto de usuários ou simplesmente ignorar esse padrão até acumular alguns meses de histórico

6. Combinando sinais com funções de janela

O padrão com funções de janela não é exatamente um tipo separado de fraude, mas uma etapa de preparação para transformar os cinco padrões anteriores em sinais combináveis
É possível criar, por transação, as seguintes colunas derivadas
- Tempo desde a transação anterior: timestamp - LAG(timestamp)
- Mudança de comerciante: comparação entre merchant_id anterior e merchant_id atual
- Valor acumulado nas últimas 24 horas: SUM(amount) OVER (...)
- Qual número da transação naquele dia: ROW_NUMBER()
Ao materializar essas colunas, as regras de fraude viram simples expressões de filtro
Dá para encontrar quadrilhas de teste de cartão com condições como
- 5ª transação do dia ou posterior
- Menos de 60 segundos desde a transação anterior
- Comerciante diferente da transação anterior
Se uma nova hipótese de fraude puder ser expressa como um filtro SQL em vez de virar um ticket de engenharia, o ciclo de iteração cai de semanas para horas
No fim, isso permite detectar mais fraudes e mais rápido

Como usar os padrões em conjunto

Nenhum padrão sozinho é suficiente
Cada padrão tem limitações claras
- Velocity gera falsos positivos como operadores de máquinas automáticas
- Deslocamento geograficamente impossível deixa passar fraudes dentro de uma mesma grande área metropolitana
- Anomalias de valor não funcionam bem fora do contexto de teste de cartão
- Regras de horário anormal exigem histórico
Na prática, funciona rodar todos os padrões e pontuar cada transação com base em múltiplos sinais
Transações que acionam três ou quatro sinais quase sempre são fraude
Transações que acionam apenas um sinal podem ser apenas um uso incomum de um titular legítimo em viagem
Se você está começando na detecção de fraudes, vale começar por Velocity
- Revela uma quantidade útil de fraude
- Captura relativamente pouca atividade legítima
- E o custo de execução é baixo
Se você já tem do item 1 ao 5, o próximo investimento é em colunas brutas baseadas em funções de janela
- Depois de criadas uma vez, todos os analistas do time podem usá-las
- E adicionar o próximo padrão de fraude deixa de ser um projeto separado

Pontos de atenção

Tratamento de NULL
- Tabelas reais de transações muitas vezes não usam NULL como nos livros introdutórios de SQL
- Muitos sistemas legados usam valores sentinela como 9999-12-31 para “sem data de término” e 0001-01-01 para “sem data de início”
- Se você filtrar com IS NULL, pode deixar essas linhas passarem despercebidas
- É preciso verificar a convenção da tabela específica antes de escrever a cláusula WHERE
Falsos positivos
- Toda regra pode capturar titulares reais com comportamento estranho, mas legítimo
- Casos sinalizados exigem revisão humana
- É necessário um ciclo de feedback para ajustar limiares com base no que era fraude de verdade e no que não era
- Bloquear automaticamente com base em uma única regra pode fazer você perder clientes
Privacidade
- Se os dados contêm PII, é preciso seguir as políticas de uso de dados aplicáveis
- Primeiro trabalhe com dados desidentificados ou de amostra, e só use dados de produção após aprovação
Custo
- Funções de janela em partições grandes não são baratas
- Filtre primeiro o intervalo de datas e só depois aplique as funções de janela
- Rodar LAG() primeiro em 2 anos de transações do dataset inteiro e só depois colocar WHERE pode consumir muito do orçamento de créditos do warehouse

4 comentários

kaydash 2026-05-17

Parece ser um método que foi adaptado do que era usado no passado nos sistemas bancários centrais e nos sistemas de canais.

GN⁺ 2026-05-17

Comentários do Hacker News

Parece que o critério de que o verdadeiro dono do cartão quase nunca compra algo de $1.00 depende de como o vendedor define o preço
Quando alguém compra algo em um site para testar um cartão de crédito roubado, essa pessoa não pode escolher livremente o valor da compra
Além disso, isso parece pensado demais para contextos como o dos EUA, onde o imposto não está incluído no preço, enquanto em outras regiões preços redondos são muito comuns
Também duvido que os outros critérios funcionem bem. Por exemplo, se você marcar alguém que fez uma transação fora do horário em que normalmente faz duas ou mais transações nos últimos 90 dias, não pegaria algo como metade das pessoas?
Não fica claro se o texto está apenas simplificando demais um conhecimento especializado complexo em consultas SQL ou se é tudo especulação e invenção. As frases “seis padrões SQL usados para pegar fraude em transações” e “não há nada aqui em que eu realmente tenha trabalhado ou visto” entram em conflito entre si
- “Transação fora do horário habitual” parece um critério bem básico
  Normalmente eu não compro gasolina, café e lanche às 2 da manhã, mas, quando isso acontece muito raramente, há uma boa chance de ser uma emergência pessoal, e eu não gostaria de ter que ligar para o banco no meio disso
  Entendo que ladrões oportunistas também podem agir nesse horário, mas o custo dos falsos positivos claramente existe
- É ainda pior. Pela minha experiência, café muitas vezes custa um valor redondo, e há gente que abastece colocando de propósito um valor exato
  Além disso, existem postos que pedem valores pré-definidos como 10, 20 ou 50 euros
- Uma noite eu estava com fome num bar e fui comprar um pacote de batatas fritas, mas havia um valor mínimo de £5 no cartão, então pedi para cobrarem £5 mesmo
  Aí o cartão foi bloqueado por suspeita de fraude, e isso foi bem irritante. Não era algo que eu queria resolver bêbado às 2 da manhã
  Talvez tenha me protegido de mim mesmo, mas ainda assim foi inconveniente
- Não sei se ainda usam isso, mas antigamente alguns hotéis e locadoras faziam uma transação de $1.00 para verificar a validade do cartão antes de reservar um quarto ou alugar um carro
- Esse método é fácil de contornar colocando um pequeno ruído nas transações de teste, e também poderia ser melhorado facilmente com uma análise estatística adequada
  E reconhecimento heurístico de padrões como esse, em que ninguém espera quase 100% de precisão, não seria justamente uma área em que a IA deveria se sair bem?
O critério de “cruzar fronteiras em 10 minutos é organização internacional” também pode se aplicar a pessoas comuns que vivem em regiões fronteiriças da Europa
Mesmo excluindo transações sem presença do cartão, parece assumir de forma errada que todas as localizações dos comerciantes estão configuradas com precisão, que todas as vendas acontecem em lojas físicas, que não existem vendedores móveis e que tudo é processado online
- Algumas semanas atrás, quando fui dos EUA para o Canadá, provavelmente também levei uns 10 minutos
Se você ler até o fim, aparecem conselhos vazios e contraditórios. Quase certamente parece um texto gerado por LLM
Diz que “sua equipe” não deve depender de nenhum padrão isolado, mas também afirma que só o padrão 1 já pode revelar “uma quantidade útil de fraude”
Também há frases estranhas como “todos os analistas da sua equipe vão usá-las, isto é, funções de janela, e adicionar o próximo padrão de fraude deixa de ser um projeto”
Além disso, quase todos os exemplos nem usam IS NULL, mas aparece uma discussão pouco relevante sobre filtros IS NULL poderem não ser aplicados; e no único exemplo em que aparece, o contexto é outro
No geral, é um texto longo demais e de baixa qualidade
Hacker News, isso precisa ser apontado
“Fixel Smith” é uma persona criada por IA, e o texto quase não tem relação com análise de fraude. Esse nome é usado em praticamente toda identidade imaginável: músico (1), romancista (2), analista de fraude (3), influenciador (4) etc.
O post tem mais de 220 pontos e mais de 70 comentários, mas quase ninguém percebeu que isso parece bem falso, e ninguém notou que se trata de uma persona gerada por IA
- Parece que o Hacker News criou recentemente o hábito frustrante de promover esse tipo de postagem de IA de baixa qualidade
  Fico me perguntando se essa enchente de IA revela uma verdade incômoda sobre o discernimento da comunidade ou se é apenas uma falha dos mecanismos de defesa existentes, algo que bastaria corrigir
- Eu estava vendo o post no celular e só dei uma passada rápida pelos comentários. Nem sempre é fácil dizer se algo foi gerado por IA ou só editado, mas aqui dava para perceber de cara só pelas citações
  Se assumirmos que todos os comentários foram feitos de boa-fé, então é bem preocupante que até aqui a alfabetização em IA seja baixa
- Mesmo olhando por cima, parece uma pessoa extremamente prolífica ou um bot
  Os romances quase não têm relação com os textos analíticos, e os textos analíticos parecem ter estilo de LLM, então o conjunto inteiro é suspeito. Considerando que o tema original era fraude, a ironia é grande
- Eu ficaria mais surpreso se a maioria das pessoas tivesse o hábito de investigar o autor de tudo que lê
  Sinceramente, eu normalmente nem olho a assinatura, muito menos outras partes do site
- Isso claramente é um texto que existe de fato. Claro que parece escrito por LLM, mas, se a pior crítica que se pode fazer é que parece um LLM, talvez isso não seja uma crítica substancial
  Não está claro se o conteúdo foi inventado ou não, mas dá para criticar o texto sem especular se foi escrito por LLM ou se é ficção. Há falhas muito mais concretas
Estamos desenvolvendo o framework open source de segurança tirreno
Tenho dúvidas sobre a abordagem descrita aqui. Por exemplo, viagem impossível é uma técnica legítima e amplamente usada, mas isso está relacionado ao comportamento de usuários online com base em endereços IP
No tirreno, há regras separadas para casos em que está claro que o IP veio de Apple Relay ou VPN/Tor, e essas são sinalizações distintas
Acho que alguns ou todos os exemplos foram gerados por LLM. O contexto está misturado, e ninguém coleta em massa localização GPS em pagamentos com cartão na prática
1. https://github.com/tirrenotechnologies/tirreno
Isso se parece mais com lógica baseada em regras codificada em consultas SQL sem dados que a sustentem
Há um monte de limiares, mas nenhum dado mostrando que esses limiares fazem sentido
A afirmação categórica do tipo “detecção de fraude em dados transacionais é majoritariamente SQL, não machine learning, banco de dados em grafo ou qualquer coisa que o Gartner esteja promovendo este ano” só se justifica quando se está falando de todo o trabalho de integridade de programas
Se resolver o domínio do problema, uma abordagem mais simples e mais grosseira pode ser melhor
Clientes de fintech normalmente querem saber se a transação que está acontecendo agora é fraude, e querem a resposta em poucos milissegundos sobre dados de alta dimensionalidade. Esse é um tipo de trabalho em escala em que um banco de dados relacional pode ter dificuldade para atender às restrições de tempo real, sendo usado em vez disso para outras finalidades, como carga de dados históricos
É por isso que entram bancos de dados em memória, engines de processamento de streams e até machine learning
Ainda assim, alguns pontos do autor são válidos, e especialmente o problema de lidar com alertas ruidosos é uma questão geral que vai além de engenharia de performance, então fico curioso pelo próximo texto
- Pela minha experiência, o que foi descrito se encaixa melhor em prevenção de fraude do que em detecção de fraude, de forma mais específica. Em configurações maduras, os dois coexistem e se complementam
  Na prevenção, sempre há restrições de latência, dos dados disponíveis e de um retrato incompleto do comportamento do usuário. Machine learning e regras são usados para tomar decisões rápidas e cobrir a maioria dos casos, mas, por causa dessas restrições, não é possível bloquear toda fraude com precisão
  A detecção lida com o que acontece depois. É comum uma equipe de analistas examinar transações aprovadas em busca de sinais de fraude. Isso é especialmente importante em tipos de fraude sem sinais externos como chargeback ou reclamação do cliente. Integridade de plataforma é um exemplo, e sistemas antifraude para prevenção à lavagem de dinheiro em fintech também precisam sair à procura de fraude
  Eles são complementares porque as transações detectadas viram os rótulos para treinar e avaliar o próximo modelo de prevenção
Disseram que, se um cartão passar em Chicago e 7 minutos depois em Los Angeles, um dos dois é falso, mas fico pensando como isso funciona em compras online
Se eu estou no sofá comprando algo na Amazon, qual endereço é registrado?
Também parece possível um caso-limite em que um casal compartilha uma conta online, e uma das pessoas compra durante uma viagem usando os dados do cartão salvos
- Passar, inserir ou aproximar o cartão é uma transação com presença do cartão. Digitar o número do cartão, como em compras online, é uma transação sem presença do cartão
  Varejistas e bancos conseguem distinguir essa diferença
- Dá para distinguir pelos metadados da transação. Já trabalhei em uma empresa de cartão de crédito
- Pelo que eu sei, o sistema distingue cartão presente de cartão não presente
“Esse método não funciona até haver histórico suficiente, e contas novas não têm linha de base” é um fator subestimado de experiência do cliente
Se meu cartão é recusado quando sou cliente novo ou quando apresento um padrão novo, parece que o software está fazendo seu trabalho
Mas, se a transação é recusada apesar de haver um histórico autenticado meu, fico irritado com um algoritmo ingênuo e paranoico
- O incentivo do banco é reduzir fraude
  No fim, transações fraudulentas viram cancelamento ou reembolso, e o banco absorve a perda. Transações recusadas só criam um cliente irritado, que reclama e logo esquece. Então o peso desse custo externalizado recai sobre o cliente
  Por isso, os bancos têm incentivo a errar pelo lado da cautela e recusar transações mesmo com falsos positivos
Não é justamente essa a essência de machine learning, aprender essas regras a partir dos dados?
Acho que a abordagem correta seria usar um modelo de machine learning para encontrar padrões associados à fraude e depois avaliar se algum deles faz sentido. Assim, talvez desse para descobrir novas hipóteses
- Algo que não seja explicável e deterministicamente refinável é arriscado demais para o trabalho de recusar transações financeiras
  Um analista humano precisa conseguir explicar à equipe de compliance, em um e-mail de 5 minutos, por que uma determinada transação foi recusada e o que deveria ter sido diferente para evitar a decisão adversa
  Muitas vezes, ao corrigir um problema com machine learning, surgem dois novos problemas que ainda não estão claros. Em termos de regressão ou efeitos colaterais inesperados ao longo do tempo, SQL geralmente traz menos surpresas

aliveornot 29 일 전

Eu estava me perguntando o que era “valor redondo”... então era rounded.

xguru 29 일 전

Por que traduziram isso desse jeito? T_T Eu já corrigi.