Fintomico
Aprenda a calibrar regras de segurança que reduzem o limite do cartão em tempo real baseadas na distância entre o celular e a compra, evitando o bloqueio total.
Implementar segurança bancária é um exercício de equilíbrio entre proteger o patrimônio e não humilhar o cliente na fila do supermercado. Em 2026, a fraude de cartão clonado continua evoluindo, mas bloquear transações de forma binária — "aprova" ou "rejeita" — custa caro em churn e suporte. A solução madura que tenho visto funcionar melhor em bancos digitais é a modulação dinâmica de limites baseada em geolocalização. Em vez de cortar o acesso, você aperta o grifo.
O foco aqui não é ligar um GPS e achar que está seguro. É sobre criar regras de business logic que cruzam a posição do dispositivo móvel (Device ID) com a localização do Point of Sale (POS) ou IP da transação. Se a geometria não fechar, o limite cai, exigindo uma segunda autenticação ou barrando gastos altos.
Abaixo, detalho a arquitetura de cinco regras essenciais para essa implementação, baseadas em ajustes que fizemos em engines de risco recentes.
O erro clássico de times de segurança junior é configurar a geolocalização como um gatilho de "kill switch". O regra é simples: se o cartão é usado em Curitiba e o celular está em São Paulo, bloqueia. O problema? A latência das redes móveis e a precisão do GPS variam. Um cliente no aeroporto de Congonhas pode ter um IP roteado por um servidor no Rio de Janeiro por questões de balanceamento de carga da operadora. Bloquear isso é uma receita para o cancelamento da conta.
A abordagem correta é o "step-down". Mantenha a transação ativa, mas reduza a exposição do banco.
Exemplo concreto:
Configure uma regra onde o limite padrão do cartão é R$ 5.000. Se a distância linear (Haversine distance) entre o último ping confiável do celular e a coordenada da loja for superior a 50 km, o parâmetro transaction_limit cai automaticamente para R$ 300,00. Isso permite que o usuário pague uma conta de restaurante ou um táxi, mas impede uma compra de eletrônicos de R$ 3.000 feita por um fraudador com a fita magnética clonada. O banco assume um risco calculado de R$ 300 em nome da experiência do usuário, mas protege o grosso do saldo disponível.
Para que o step-down funcione, você precisa calibrar o que é uma "viagem impossível". Não adianta usar uma distância fixa sem considerar o tempo. O coração da regra precisa ser uma comparação de velocidade média.
Definição da lógica: Calcule a velocidade necessária para percorrer a distância entre o ponto A (localização do celular há 10 minutos) e o ponto B (localização da transação atual).
Onde isso falha? Em trechos de rodovia duplicada. Um cliente no carro a 120 km/h pode fazer uma compra em um drive-thru via wireless POS, mas o GPS do celular pode ter atualizado 5 minutos atrás na cidade anterior. Por isso, a regra de velocidade não pode ser o único fator; ela serve apenas para derrubar o limite automaticamente e não negar a venda. Isso exige um core bancário resiliente, capaz de alterar limites em milissegundos. Se você ainda brigas com latência de core monolítico, essa lógica vai frustrar o usuário com timeouts.
A regra mais eficiente para detectar clonagem não é olhar para onde o cliente não está, mas sim verificar se o celular está "tocando" o estabelecimento. Em 2026, a maioria das transações físicas ainda depende do cartão plástico ou da digitalização no NFC, mas o token deve estar atrelado ao Device ID do smartphone.
A implementação deve exigir que o app do banco envie as coordenadas de alta precisão (frequência GNSS ajustada) sempre que o usuário desbloqueia a tela. Se houver uma tentativa de transação EMV (chip) em um POS em Recife, e o últimoheartbeat do app indicar que o dispositivo está em Brasília, você tem dois cenários:
Em ambos, o risco é alto. A regra deve ser: sem confirmação de co-location (mesma cidade ou raio de 5km), qualquer transação acima de R$ 100 requer biometria facial ou senha de 6 dígitos. Se o POS suportar 3DS 2.3, o challenge biometrico aparece na tela da maquininha ou no celular do usuário. Se o celular estiver em outra cidade, o challenge falha ou o banco envia um SMS para o número cadastrado (que pode estar comprometido, daí a preferência pela app-auth).
Implementar isso sem tratar a imprecisão técnica vai gerar mais falsos positivos do que fraudes evitadas. Em áreas urbanas densas, como a região da Faria Lima ou o Centro do Rio, o GPS pode saltar 300 metros por reflexão de sinal em prédios (fenômeno multipath). Se o usuário estiver no térreo do shopping e o GPS "voar" para o quarteirão ao lado, você não pode puni-lo.
A solução técnica é criar uma "Zona de Tolerância" baseada na densidade de estabelecimentos comerciais.
Configuração Prática:
Além disso, implemente um filtro de "smoothing" (suavização). Não considere um único ponto isolado de GPS como verdade absoluta. Use uma média dos últimos 3 pontos coletados nos últimos 5 minutos. Se houver um outlier (um ponto distante), descarte-o. Isso evita que um erro momentâneo de triangulação da operadora de celular faça o limite do cartão cair de R$ 5.000 para R$ 100 quando o cliente está apenas pagando o estacionamento.
Todo algoritmo tem cegueiras. A principal é o acesso à internet. Se o cliente viaja para o exterior e desliga o roaming de dados para economizar, ou está em um navio de cruzeiro com conexão via satélite instável, o banco vai ver o último ponto conhecido no Brasil. Quando o cartão passar em Lisboa, a distância vai ser impossível e o limite vai ser triturado.
Você não pode adivinhar que ele está de férias. O usuário precisa declarar.
O botão "Vou Viajar" no app não pode ser apenas uma configuração de preferência; ele deve modificar os parâmetros da policy de risco daquela conta específica no motor de decisões. Ao ativar "Viagem Internacional" com destino a Portugal, o sistema deve:
O erro que vejo com frequência é o usuário marcar a viagem no app, mas o sistema de fraude não ler esse flag em tempo real devido à arquitetura legada. O flag deve viajar no payload da autenticação do token.
Concluindo, a mágica da segurança em 2026 não é impedir a fraude a todo custo (isso é impossível), mas tornar o ataque economicamente inviável ou operacionalmente cansativo para o fraudador, enquanto o cliente legítimo sente apenas um "solavanco" leve no seu limite. Reduzir o teto dinamicamente é a forma mais elegante de dizer "não confio nessa transação 100%, mas confio enough para não te deixar na mão". Lembre-se que nenhum algoritmo geográfico é à prova de falhas; comprometimento total do dispositivo (malware no Android) pode falsificar coordenadas, por isso isso deve ser apenas uma camada de uma defesa em profundidade.
Um relato franco sobre a perda de garantias ACID, o aumento de 40% na infraestrutura e o trabalho silencioso de reconciliação para mover 2 milhões de CPFs sem quebrar o Banco Central.
CISOs estão jogando dinheiro fora blindando o dispositivo enquanto o verdadeiro elo fraco continua acessando o app: o humano sob pressão.
