Definição
O transaction monitoring (monitoramento transacional) acompanha continuamente — em tempo real ou em lote — os fluxos de um cliente para detectar operações atípicas ligadas à lavagem de dinheiro, ao financiamento do terrorismo ou à fraude.
É o elo operacional entre o onboarding KYC ("sei quem é") e a comunicação de suspeição à TRACFIN ("sinalizo o que é anormal"). Combina motores de regras, modelos de ML e equipes de analistas.
O pipeline típico
- Ingestão: transações, KYC, contexto do dispositivo, histórico.
- Enriquecimento: geolocalização, MCC, classificação do beneficiário, scoring do dispositivo.
- Cenários: regras determinísticas e modelos de ML (anomalias estatísticas).
- Alertas sobre transações ou clientes de risco.
- Triagem: auto-clear ou auto-block em algumas, escalonamento das demais.
- Revisão humana por um analista, que confirma ou rejeita.
- Ação: bloqueio, pedido de informação, comunicação à TRACFIN, reporte.
PLD-FT vs antifraude
Muitas vezes na mesma ferramenta, dois objetivos distintos:
- PLD-FT: detectar lavagem, terrorismo, fraude fiscal — horizonte de médio/longo prazo, ação = comunicação à TRACFIN.
- Fraude: detectar conta comprometida, fraude APP, fraude com cartão — horizonte em tempo real, ação = bloqueio antes da execução.
Os fornecedores modernos (Hawk, Sardine, Featurespace, Feedzai) oferecem os dois em uma única plataforma.
Cenários clássicos
- PLD-FT: structuring/smurfing (pequenos valores abaixo do limite), conta de passagem, países de risco, atividade incoerente com o perfil, network analysis (contas vinculadas), uso intensivo de dinheiro em espécie.
- Fraude: login a partir de um novo dispositivo seguido de transferência, primeira transferência para um IBAN estrangeiro desconhecido, teste de cartões roubados, geolocalização incoerente, velocity, padrão de laranja (mule).
Regras vs ML
- Regras determinísticas: auditáveis, mas com muitos falsos positivos (até 95% nos players históricos).
- ML supervisionado: mais preciso, menos falsos positivos, mas exige rótulos (alertas confirmados).
- ML não supervisionado: detecta anomalias sem rótulo, útil para novos tipos de ataque.
- Híbrido: regras + ML + human-in-the-loop, os melhores scores do mercado.
O verdadeiro debate: ML opaco vs explicabilidade. A ACPR exige entender por que uma transação é bloqueada — daí os modelos explicáveis (SHAP, surrogate trees).
O desafio do volume de alertas
Um banco de porte médio gera vários milhares de alertas por dia. Metas de um bom motor: menos de 10% de alertas confirmadas, mais de 50% tratadas automaticamente e de 5 a 30 minutos de tratamento humano por alerta restante. A otimização contínua (revisão das regras, retreinamento do ML, caça aos falsos positivos) é um trabalho de tempo integral.
O que o transaction monitoring não é
- Não substitui o KYC: sem um perfil de referência, ele é cego.
- Não é garantia de zero fraude: nenhuma solução pega 100% dos casos.
- Não é bloqueio automático em massa: bloquear demais gera reclamações, sanções da ACPR e custos.
- Não é estático: regras e modelos devem ser revistos continuamente (drift).
No ecossistema PSD2
É uma obrigação de PLD-FT (AMLD), portanto exigida de todos os PSPs da PSD2, e uma questão da PSD2/PSR sobre a fraude APP (identificar transações suspeitas antes da execução). A DORA acrescenta uma exigência de resiliência operacional sobre o próprio sistema de monitoramento.
Exemplos concretos
- Especialistas: Hawk (DE, ML-first), ComplyAdvantage (UK), Sardine (EUA, cripto + fintech), Featurespace (UK), Feedzai (PT), Quantexa (network analysis), NICE Actimize e SAS AML (grandes contas).
- Neobanco: um cliente recebe € 5.000 de um IBAN desconhecido e retransfere € 4.800 para uma carteira de cripto em 5 minutos → alerta → revisão em 10 min → pedido de justificativa → bloqueio e comunicação à TRACFIN se insuficiente.
- Fraude APP: uma transferência de € 8.000 para um novo beneficiário às 22h aciona um atrito (pop-up, prazo de 24h, verificação por telefone), com quedas de fraude relatadas pelos grandes bancos.
- Solaris (DE): sancionada pela BaFin em 2023 por falha no monitoramento (teto de crescimento, reformulação do motor).
- Escala: tendo passado de 1 a 10 mi de clientes, o Revolut teve de repensar seu motor (apenas regras → ML + equipes 24/7).
- Custo: € 0,1 a € 1/cliente/ano de ferramenta mais ~1 FTE para 50 a 100 mil clientes ativos — ou seja, € 2 a € 4 mi/ano para 1 mi de clientes.
- Evolução: graph analytics para as redes de laranjas e o compartilhamento de sinais entre bancos (projeto UK Finance), a equilibrar com o RGPD.