Prevenção a fraude com análise de dados no financeiro

A fraude não avisa, ela some no meio de milhões de transações legítimas#

Em banco, fintech, adquirente, cooperativa de crédito ou meio de pagamento, o volume trabalha contra você. Uma transação fraudulenta parece igual a mil transações honestas até que alguém olhe o contexto: o horário estranho, o dispositivo novo, o valor fora do padrão daquele cliente, a sequência rápida de tentativas. Prevenção a fraude com dados é exatamente esse trabalho de dar contexto ao que, isolado, não chama atenção. Não é mágica e não é um botão que a diretoria compra pronto. É uma combinação de regras claras, escore, detecção de anomalia e um bom painel para o analista investigar sem perder duas horas juntando planilha.

Antes de avançar, uma honestidade que economiza projeto: o BI não é o sistema que bloqueia a transação. Quem barra o pagamento no momento em que ele acontece é um sistema transacional antifraude, um gateway ou um motor de decisão que responde em milissegundos. O papel do BI e do analytics é outro, e igualmente valioso: monitorar o que está passando, medir a qualidade das regras, alimentar e avaliar modelos, e dar ao investigador a tela onde o caso se resolve. Confundir os dois papéis é a forma mais rápida de frustrar todo mundo.

O BI apoia a investigação, ele não substitui o motor antifraude#

Vale separar bem as camadas, porque essa confusão gera expectativa errada e projeto que nasce torto.

Camada	Função	Tempo de resposta	Ferramenta típica
Motor transacional antifraude	Aprovar, negar ou desafiar a transação no ato	Milissegundos	Gateway, motor de decisão, regras em produção
Escore e modelo	Atribuir risco a cada evento	Milissegundos a minutos	Azure Machine Learning, Data Science do Fabric
Monitoramento e alerta	Vigiar padrões, disparar filas de análise	Quase em tempo real a minutos	Fabric, streaming, pipelines
Painel de investigação	Dar contexto para o analista decidir o caso	Interativo, sob demanda	Power BI

O que o BI faz bem é o de baixo dessa tabela. Ele não vai bloquear nada, mas vai responder por que uma regra começou a barrar clientes bons, quanto está custando o falso positivo, quais canais concentram tentativa de fraude no mês e como o modelo se comportou desde o último retreino. Esse tipo de leitura é o que sustenta a decisão de negócio em cima do antifraude. É trabalho de analytics avançado e de boa engenharia de dados, não de um dashboard bonito sozinho.

Regras e escore resolvem a maior parte antes de chamar machine learning#

Existe uma pressa cultural de pular direto para inteligência artificial. Na prática, a maior parte do valor em antifraude ainda vem de duas técnicas antigas e bem entendidas: regras e escore.

Regras são condições explícitas e auditáveis. Transação acima de um valor, em país diferente do usual, com cartão recém cadastrado, fora do horário do cliente. A vantagem é enorme para um setor regulado pelo Banco Central: a regra é explicável. Você consegue dizer, com todas as letras, por que aquela transação foi marcada. A desvantagem é que fraudador aprende o limite e contorna. Por isso regra sozinha envelhece.

Escore soma sinais e devolve um número de risco. Em vez de um corte seco, você combina dezenas de indícios e calibra o limiar conforme o apetite de risco. É aqui que a análise de dados no financeiro começa a brilhar, porque o escore permite priorizar: em vez de tratar tudo igual, o analista ataca primeiro os casos de maior risco.

Detecção de anomalia entra quando o padrão de fraude é novo e ninguém escreveu regra ainda. A ideia é modelar o comportamento normal de um cliente, de um dispositivo ou de um estabelecimento e sinalizar o que foge disso. Anomalia não é prova de fraude, é candidato a investigação. Essa distinção precisa estar clara para o time, senão vira caça às bruxas contra cliente bom.

Técnica	Quando usa	Força	Limite honesto
Regras	Padrões conhecidos e explicáveis	Auditável, rápida de ajustar	Fraudador aprende e contorna
Escore	Priorizar risco combinando sinais	Calibra corte por apetite de risco	Exige monitorar deriva do escore
Detecção de anomalia	Padrão novo, sem regra escrita	Pega o que ninguém previu	Gera falso positivo, precisa de investigação
Modelo supervisionado	Há histórico rotulado de fraude	Aprende relações complexas	Depende de rótulo bom e retreino

O falso positivo é o custo que ninguém coloca na conta#

Todo mundo mede fraude bloqueada. Pouca gente mede o cliente bom que levou não. Falso positivo é a transação legítima marcada como suspeita, e ele custa de três formas: atrito com o cliente, custo operacional de investigar caso que não era nada, e receita perdida na compra que não aconteceu. Um antifraude apertado demais parece ótimo no relatório de fraude evitada e péssimo no churn do trimestre seguinte.

O trabalho de dados aqui é tornar esse custo visível. Um painel maduro mostra, lado a lado, a taxa de detecção e a taxa de falso positivo por regra, por canal e por faixa de valor. É essa leitura que permite conversas adultas: aquela regra pega dez fraudes por mês e barra oitocentos clientes bons, vale a pena? Sem o número, a discussão vira opinião. Com o número, vira decisão. Recomendo tratar falso positivo como métrica de primeira classe, no mesmo nível da fraude evitada, e nunca deixá-lo escondido atrás do indicador que agrada a diretoria.

Monitoramento quase em tempo real é o que dá reação, não relatório de ontem#

Fraude tem janela curta. Um relatório que fecha no dia seguinte serve para aprender, não para reagir. Por isso o desenho de dados para antifraude precisa mirar latência baixa no monitoramento, mesmo que a investigação seja interativa.

Na prática, isso significa um pipeline que captura eventos em fluxo, aplica regras e escore, e materializa filas de alerta que o analista vê em minutos, não no dia seguinte. O Microsoft Fabric ajuda nesse desenho ao juntar ingestão, processamento e o modelo de dados na mesma plataforma, o que reduz a quantidade de peças móveis entre o evento e a tela. Se você está avaliando a plataforma, vale ler o guia de Fabric antes de decidir arquitetura.

Um alerta de vocabulário: quase em tempo real não é tempo real. O bloqueio em tempo real é do motor transacional. O monitoramento em dados opera em segundos ou minutos, tempo suficiente para acionar investigação, revisar limites e conter um ataque em andamento, mas não para barrar a transação individual no instante do clique. Prometer tempo real com BI é criar expectativa que a ferramenta não entrega.

Painel de investigação bom é o que resolve o caso sem exportar para o Excel#

O analista de fraude não quer um dashboard executivo com números redondos. Ele quer o caso na tela: o histórico do cliente, o dispositivo, a geolocalização, as tentativas recentes, os valores, o escore e o motivo do alerta. Um bom painel de investigação em Power BI resolve isso reunindo o contexto em um só lugar, com drill do agregado até a transação individual e a possibilidade de o analista marcar o desfecho, fraude confirmada, falso positivo ou inconclusivo.

Esse desfecho fecha um ciclo importante. O rótulo que o investigador cria vira insumo para avaliar regras e retreinar modelo. Sem essa captura estruturada, o modelo aprende com dado velho e o time repete os mesmos erros. Um painel que só mostra e não deixa registrar decisão é meio caminho, não solução.

Boas práticas de modelagem contam muito aqui. Fraude trabalha com colunas de altíssima cardinalidade, como id de transação, id de dispositivo e cartão. O motor VertiPaq do Power BI comprime dados por cardinalidade, ou seja, colunas com muitos valores distintos comprimem pior e pesam mais no modelo. Trazer id de transação cru para dentro do modelo semântico é um erro comum que estoura memória sem necessidade. O caminho é manter o grão detalhado na camada de dados e levar ao modelo semântico apenas o que a investigação realmente precisa navegar. Quem quiser aprofundar a técnica encontra base no material de boas práticas de DAX.

Modelo entra quando há histórico rotulado, e vive no Azure ou no Fabric#

Machine learning em antifraude não nasce do nada, ele nasce de rótulo. Você precisa de um histórico de casos marcados como fraude e não fraude para treinar um modelo supervisionado. Sem esse histórico, comece por regras e anomalia, e use a operação para gerar os rótulos que vão viabilizar o modelo depois. Pular essa etapa é treinar modelo no vácuo.

Quando há dado, o modelo é treinado e servido fora do BI. As opções naturais no ecossistema Microsoft são o Azure Machine Learning, mais completo para quem já tem maturidade de MLOps, e a experiência de Data Science do Microsoft Fabric, mais integrada para quem já centralizou os dados na plataforma. Em ambos, o escore volta para o fluxo transacional ou para as filas de monitoramento. O BI entra na ponta para medir o modelo em produção: taxa de acerto, deriva, distribuição do escore ao longo do tempo. Modelo sem esse acompanhamento apodrece silenciosamente, e ninguém percebe até a fraude passar.

Uma frase que repito em projeto: modelo não é entregável final, é ativo vivo. Ele precisa de retreino, de monitoramento e de gente olhando. Se o cliente não tem estrutura para sustentar isso, o modelo vira dívida técnica cara. Nesses casos, regra bem calibrada e revisada com frequência entrega mais valor do que um modelo abandonado.

Dados de fraude são dados pessoais, e a LGPD não é opcional#

O setor é regulado pelo Banco Central e o dado que você usa para caçar fraude é, na maioria das vezes, dado pessoal. Transação, geolocalização, dispositivo, comportamento de compra. Tudo isso está sob a LGPD, a Lei nº 13.709/2018. Isso significa base legal definida, controle de acesso ao painel de investigação, trilha de auditoria de quem viu o quê, e retenção com prazo, não guardar tudo para sempre porque é conveniente.

Prevenção a fraude é uma das finalidades que costuma sustentar bem o tratamento, mas isso não dispensa governança. Um painel de investigação abre o comportamento fino do cliente, e quem acessa precisa ter razão para acessar. Tratar isso desde o desenho, e não como remendo depois de auditoria, é o que separa projeto sério de risco jurídico. Vale estruturar essa camada com governança de dados desde o começo, com papéis, segurança em nível de linha e registro de acesso.

Perguntas frequentes#

BI substitui um sistema antifraude?

Não, e essa é a resposta mais importante do texto. O bloqueio da transação no ato é feito por um motor transacional que responde em milissegundos. O BI e o analytics monitoram padrões, medem qualidade de regras e modelos, e dão ao analista a tela para investigar. São camadas complementares, não concorrentes. Quem contrata BI esperando bloqueio em tempo real vai se frustrar.

Preciso de machine learning para começar?

Não. A maior parte do valor inicial vem de regras claras, escore e detecção de anomalia, que são técnicas padrão, auditáveis e explicáveis, o que importa muito em setor regulado. Modelo supervisionado só faz sentido quando existe histórico rotulado de fraude para treinar. Comece pelo básico e use a operação para gerar os rótulos que viabilizam o modelo depois.

Como controlo o falso positivo?

Medindo. Um painel maduro mostra taxa de detecção e taxa de falso positivo lado a lado, por regra, canal e faixa de valor. Com esses números, a discussão sobre afrouxar ou apertar uma regra deixa de ser opinião e vira decisão baseada em custo real, incluindo atrito com o cliente e receita perdida, não só fraude evitada.

Qual a diferença entre tempo real e quase em tempo real?

Tempo real é o motor transacional decidindo no instante do clique, em milissegundos. Quase em tempo real é o monitoramento em dados operando em segundos ou minutos, tempo de acionar investigação e conter um ataque em andamento, mas não de barrar a transação individual. Confundir os dois cria expectativa que a plataforma de dados não cumpre.

Onde treino e sirvo o modelo?

Fora do BI. No ecossistema Microsoft, as opções naturais são o Azure Machine Learning, para quem tem maturidade de MLOps, e a experiência de Data Science do Microsoft Fabric, para quem já centralizou os dados na plataforma. O escore gerado volta ao fluxo transacional ou às filas de monitoramento, e o Power BI acompanha o desempenho do modelo em produção.

Isso tudo respeita a LGPD?

Precisa respeitar. Dados de transação, dispositivo e geolocalização são dados pessoais sob a Lei nº 13.709/2018. Prevenção a fraude costuma sustentar a base legal, mas você ainda precisa de controle de acesso ao painel, trilha de auditoria e política de retenção. Governança tem que estar no desenho, não como remendo depois.

Onde a Fynx entra#

Prevenção a fraude com dados é um trabalho de camadas: pipeline de baixa latência, regras e escore bem calibrados, modelo servido no Azure ou no Fabric, e um painel de investigação que resolve o caso sem exportar nada para o Excel. Nenhuma dessas peças vale sozinha, e nenhuma delas substitui o motor transacional que barra a fraude no ato. O que entrega resultado é o conjunto montado com honestidade sobre o que cada parte faz.

Se você quer estruturar monitoramento, escore e painéis de investigação sem prometer o que a ferramenta não faz, fale com a gente.