Uma jornada técnica e analítica que descreve como dados, processos ELT, regras de negócio e análises em Python formam um sistema integrado de combate a crimes financeiros.
A lavagem de dinheiro é um crime financeiro que disfarça a origem ilícita de fundos, tornando-os aparentemente legítimos. Ela afeta a estabilidade econômica e a integridade dos sistemas financeiros globalmente.
Contexto fictício: os dados, clientes e transações utilizados neste projeto são completamente fictícios e têm finalidade exclusivamente demonstrativa. Nenhuma informação real foi utilizada.
Inserção dos recursos ilícitos no sistema econômico via depósitos, compra de instrumentos ou bens, frequentemente em países com menor regulação.
Quebra da trilha contábil por meio de transferências eletrônicas para contas anônimas, dificultando rastreamento por autoridades.
Os recursos retornam ao sistema econômico formal, aparentemente "limpos", prontos para uso pelas organizações criminosas.
A análise de dados oferece uma abordagem baseada em evidências para identificar e mitigar essas atividades suspeitas, tornando-se um aliado essencial do Compliance.
O coração operacional do projeto: a extração, transformação e carga dos dados de movimentações financeiras que alimentam toda a análise. A técnica de ingestão varia conforme o cenário e a infraestrutura de cada cliente.
Processo de Extração, Transformação e Carga. Os dados são transformados numa camada intermediária antes de chegar ao destino final — abordagem tradicional quando o destino tem pouca capacidade de processamento.
Processo de Extração, Carga e Transformação. Coleta dados de diversas fontes, os carrega primeiro em formato bruto no destino e só então aplica as transformações — abordagem comum quando o próprio banco de destino tem poder de processamento para transformar (como aqui, via procedure SQL).
Pacotes de Integration Services para orquestração de fluxos em ambiente SQL Server — a técnica usada neste projeto.
Ver repositório →Scripts customizados para ingestões flexíveis, com controle total sobre validação e transformação dos dados.
Ver repositório →Cargas de alto volume direto no banco, priorizando performance em cenários de arquivos grandes.
Ver repositório →Extração direta de views disponibilizadas na base do cliente, sem necessidade de arquivo intermediário.
Leitura direta de volumes em nuvem, para cenários em que a origem dos dados já está hospedada em provedores como AWS, Azure ou BigQuery.
Ver repositório →DAGs para orquestração e agendamento de pipelines mais complexos, com múltiplas dependências entre etapas.
Ver repositório →Leitura e parsing de arquivos .json, comuns em integrações com sistemas que exportam dados semiestruturados.
Ver repositório →Consumo direto de API do cliente ou de terceiros, sem etapa intermediária de arquivo, para ingestões em tempo real ou sob demanda.
Fonte dos dados neste projeto: informações de clientes e operações realizadas em D-1 (dia anterior ao processamento), extraídas diretamente da base de origem do cliente. Esse ciclo de atualização pode ser adaptado conforme a necessidade de cada cliente — aqui, D-1 garante que as análises reflitam sempre as movimentações mais recentes disponíveis.
Geralmente ocorre na sequência abaixo, mas pode haver alterações no fluxo dependendo do cliente ou produto.
Antes de iniciar a carga, a tabela de staging é limpa para garantir que não haja duplicidade ou dados residuais de execuções anteriores.
Os dados são lidos, validados e seus registros carregados na tabela destino do banco de dados, incluindo dados de clientes e operações do dia anterior.
Uma procedure SQL é disparada para consolidar e atualizar as tabelas relacionadas a clientes e operações com os dados recém-carregados.
As tabelas de clientes e operações estão atualizadas e prontas para alimentar as regras de detecção e os relatórios analíticos.
Com os dados carregados, o motor de regras entra em ação. A primeira regra avalia movimentações de valores acima de um limiar definido pelo Compliance.
Identifica transações com valor igual ou superior ao Parâmetro01 — definido pela área de Compliance. Todas as movimentações no período analisado são verificadas automaticamente.
Após a análise, as movimentações que acionam a regra são separadas em tabelas dedicadas, criando uma fila de trabalho para verificação pelas áreas responsáveis.
Resultado desta etapa: as operações suspeitas ficam isoladas em tabelas independentes, prontas para revisão pelo time de Compliance — sem misturar dados limpos com alertas.
A análise aprofundada combina a precisão do SQL com a expressividade do Python para transformar dados brutos em insights acionáveis.
Usando a biblioteca pymssql, Python se conecta diretamente ao banco para executar queries e retornar DataFrames prontos para análise.
# Importando bibliotecas essenciais import pandas as pd import pymssql as sql # Criando conexão com o banco conexao = sql.connect('servidor', 'usuario', 'senha', 'banco_de_dados') # Consultando alertas gerados df = pd.read_sql_query(""" SELECT COUNT(*) AS quantidade FROM dbo.tgr_alertas WHERE cd_enquadramento = 1 AND dt_movimentacao = '2020-07-31' """, conexao) conexao.close()
Em 31/07/2020, a execução da regra de alto valor gerou 95 alertas para revisão pelo Compliance.
| Métrica | Valor | Data referência | Status |
|---|---|---|---|
| Total de alertas | 95 | 2020-07-31 | Para revisão |
Os 15 clientes com mais alertas foram identificados e ranqueados para priorização no processo de verificação.
| # | Cód. Cliente | Alertas | Prioridade |
|---|---|---|---|
| 1 | 196592 | 9 | Alta |
| 2 | 207703 | 9 | Alta |
| 3 | 182151 | 7 | Alta |
| 4 | 143577 | 5 | Média |
| 5 | 22339 | 4 | Média |
| 6 | 846017 | 4 | Média |
| 7 | 865396 | 4 | Média |
| 8–15 | Demais clientes | 1–3 | Normal |
Insight: a maior concentração de alertas por cliente está entre 3 e 4 ocorrências. Clientes com 7 ou mais alertas devem ser investigados prioritariamente pelo time de Compliance.
A análise de correlação entre o volume de movimentações e a quantidade de alertas revela quais produtos financeiros concentram maior risco.
Correlação importante: embora Conta Corrente seja o produto com maior volume de movimentações (71 mil), a Corretora concentra proporcionalmente mais alertas. Isso sugere que operações de corretagem merecem atenção especial nas regras de detecção.
Este projeto demonstra como a integração de ETL/ELT (implementada via SSIS e Bulk Insert), Stored Procedures para consolidação dos dados, regras de negócio baseadas em Compliance e análises em SQL + Python cria um pipeline robusto de prevenção à lavagem de dinheiro — do dado bruto à decisão fundamentada.