Melhores Plataformas de Monitoramento de Transações de PLD: Uma Estrutura de Avaliação

Última atualização: Setembro de 2026

As melhores plataformas de monitoramento de transações de PLD (Prevenção à Lavagem de Dinheiro) não podem ser escolhidas a partir de uma lista de classificação, porque um ranking não diz nada sobre como uma plataforma se comportará com os seus alertas. Para um banco, cooperativa de crédito ou fintech, a melhor plataforma de monitoramento de transações de PLD é aquela que prova, com os dados históricos e em tempo real da própria instituição, que gera alertas que os investigadores conseguem fechar com mais rapidez e fundamentação, mantendo intacta a cobertura de tipologias. Essa prova vem de um exercício que testa a qualidade dos alertas e o processo do investigador de forma conjunta, pontua cada caso encerrado e compara os resultados com os dos próprios analistas da instituição. Este guia explica como realizar esse exercício e o que documentar a partir dele, já que a escolha da plataforma se torna algo que um auditor pode questionar.

Resumo (TL;DR)

• A plataforma certa é aquela que prova, com os seus próprios dados, que os investigadores conseguem encerrar os alertas de forma mais rápida e defensável, com a cobertura de tipologias intacta.

• Teste a qualidade dos alertas e o processo do investigador em um único exercício e pontue o caso encerrado, pois a melhoria de um lado pode ocorrer em detrimento do outro.

• Execute o teste em fluxos reais: um teste retrospectivo (backtest) em uma janela histórica com comunicações de atividades suspeitas (SARs) conhecidas, uma amostra cega analisada pelos seus investigadores e um período de teste em paralelo (shadowing) com dados reais, tudo comparado com as decisões anteriores dos seus analistas.

• Analise cada divergência com uma disposição anterior, pois isso pode apontar para um erro da plataforma, uma lacuna nos dados ou uma prática não documentada.

• Guarde o registro da avaliação. O modelo de um fornecedor ainda precisa ser validado pela própria instituição, e o manual do FFIEC prevê que os sistemas de monitoramento sejam validados de forma independente.

O que torna uma plataforma de monitoramento de transações de PLD a melhor para a sua instituição?

A melhor plataforma de monitoramento de transações de PLD para a sua instituição é aquela que mostra, com os seus próprios dados, que os alertas chegam a uma decisão defensável mais rápido do que hoje, mantendo a cobertura de tipologias intacta. Uma plataforma conquista essa posição ao passar por um teste com os seus dados, portanto, a mesma plataforma pode ser ideal para uma instituição e inadequada para outra. Uma decisão defensável é aquela que um auditor consegue reconstruir meses depois: qual regra ou versão do modelo disparou, quais dados o investigador viu, quais evidências e tipologias foram consideradas, o que foi decidido, por quem e por quê.

Duas métricas determinam o resultado, e elas precisam ser avaliadas juntas. A qualidade do alerta diz respeito a se a plataforma gera os alertas relevantes para os seus riscos, e o processo do investigador é a rapidez e a segurança com que um investigador vai de um alerta a uma decisão documentada. O caso encerrado captura ambos: um alerta trabalhado até uma decisão que pode ser defendida.

O manual de auditoria do FFIEC (Federal Financial Institutions Examination Council) abrange o mesmo escopo. Ele lista cinco componentes interdependentes de um sistema eficaz de monitoramento e comunicação de atividades suspeitas: identificação ou alerta de atividade incomum, gestão de alertas, tomada de decisão sobre SARs, preenchimento e envio de SARs, e monitoramento e envio de SARs sobre atividades contínuas. Uma plataforma de monitoramento afeta pelo menos os três primeiros, portanto, um teste que se limita ao alerta mede apenas um dos cinco componentes.

Os seus próprios analistas são a referência, e as decisões anteriores deles sobre os mesmos alertas são o padrão que o candidato deve atingir ou explicar. Um vice-presidente sênior de operações e inovação de um banco comunitário descreveu o único teste que faria a instituição mudar: "Você não pode mudar até provar que outra solução será igualmente boa. E a única forma que vejo de fazer isso... é configurar algo lado a lado, rodar em paralelo e avaliar um contra o outro."

Guarde os registros ao longo do caminho, pois o que você testou, em qual público, com quais resultados e por que escolheu é a evidência que um auditor poderá solicitar mais tarde. Este guia parte de uma lista de finalistas. Como criar essa lista, considerando softwares de monitoramento feitos para fraude e para PLD, é abordado em um guia separado para a escolha de softwares de monitoramento de transações.

Por que uma comparação de funcionalidades não serve para escolher a plataforma ideal

Uma comparação de funcionalidades não serve para escolher uma plataforma de monitoramento de transações de PLD porque os softwares de monitoramento de BSA/PLD em uma lista de finalistas costumam atender aos mesmos requisitos básicos, e um sinal de "visto" não diz nada sobre como a plataforma se comporta com os seus dados e com os seus investigadores. Critérios de avaliação de fornecedores estruturados como uma planilha de funcionalidades mostram, assim como uma demonstração, o que uma plataforma pode ser configurada para fazer. Nenhum dos dois mostra o dia de trabalho real de um investigador nela.

Ao descrever uma demonstração, um líder de conformidade de BSA/PLD de um banco comunitário disse: "Foi isso que me mostraram: como configurar [a plataforma]? Eu quero saber como é o dia a dia... os alertas, tipo, como eu abro casos a partir dos alertas." A avaliação precisa responder à pergunta que a demonstração deixou em aberto.

A mera equivalência de funcionalidades também não é motivo para mudar. Como disse um gerente sênior de conformidade de PLD de uma operadora de jogos online, "se todo o resto for equivalente, não vamos mudar, certo?" Uma migração custa trabalho de dados, uma execução em paralelo e a atenção do auditor, então a avaliação precisa mostrar uma diferença que justifique o custo.

O mesmo raciocínio explica por que este guia não cita plataformas: o ranking de um fornecedor baseia-se nos dados e no perfil de risco de outra empresa, e não pode dizer como a plataforma se comportará com os seus. A questão sobre quais recursos diferenciam os sistemas de monitoramento de transações tem seu próprio guia, e este texto começa onde o outro termina, focando em testar esses recursos com os seus próprios alertas.

Os auditores têm seguido a mesma linha. De acordo com um diretor global de operações de conformidade de uma empresa de cripto, os auditores costumavam julgar um programa pela quantidade de alertas e pelo número de pessoas que os revisavam, e agora perguntam se o programa é estratégico, inclusive se utiliza IA e aprendizado de máquina. Evidências dos seus próprios dados respondem a essa pergunta, mas uma lista de funcionalidades não.

O que significa qualidade do alerta no monitoramento de PLD

A qualidade do alerta no monitoramento de PLD indica a confiabilidade com que os alertas de monitoramento de transações de uma plataforma geram um trabalho relevante, como uma escalação, um caso ou uma SAR, para as tipologias mapeadas em sua avaliação de risco. Bons alertas são produtivos, cobrem os riscos necessários e baseiam-se em dados completos; o volume de alertas por si só diz muito pouco sobre esses fatores.

A taxa de conversão de alertas em SARs é uma métrica útil para análise, mas um alvo ruim para se perseguir. Em um banco digital, um subdiretor de PLD disse que a equipe monitora essa métrica como padrão, de forma agregada e incluindo encaminhamentos de fraude: "é assim que medimos se estamos recebendo bons alertas, boas revisões." Um candidato pode aumentar essa proporção simplesmente gerando menos alertas, por isso analise esse número junto com uma lista do que o candidato deixou de alertar.

Os resultados das SARs nem sempre coincidem com a regra que disparou o alerta. Um analista de conformidade em uma plataforma de cripto apontou o problema diretamente: "Às vezes, o alerta revisado resulta no envio de uma SAR, mas não é exatamente pela regra que disparou, entende?" Atribuir cada SAR a qualquer cenário que gerou o alerta mascara quais cenários realmente merecem espaço, portanto, prefira associar cada resultado a uma tipologia.

A origem das suas SARs é o teste mais real de qualidade dos alertas. Em um banco comunitário, um oficial de BSA descreveu que lidava com "falsos positivos em excesso" e disse: "A maioria das nossas SARs vem de encaminhamentos internos das agências, porque não recebemos nenhum alerta realmente bom do sistema." Quando a maioria das SARs começa como encaminhamentos, o sistema de monitoramento está falhando em seu papel, independentemente do volume de alertas. Por isso, registre a origem de cada SAR na janela de avaliação e verifique quais delas o candidato teria identificado.

A taxa de falsos positivos tem dois lados. "Se a taxa de falsos positivos for muito alta, significa que estamos perdendo muito tempo com isso. Mas se for muito baixa, podemos estar deixando passar casos realmente suspeitos", explicou um analista de BSA de um banco comunitário. Para um diretor de conformidade de PLD de um banco regional, a prioridade é clara: a equipe prefere analisar falsos positivos extras "a correr o risco de não alertar sobre algo que teríamos a obrigação de reportar." Menos alertas só geram economia se a cobertura for mantida.

A cobertura deve seguir a sua própria avaliação de risco, em vez de uma biblioteca genérica de cenários. O manual do FFIEC afirma que a sofisticação dos sistemas de monitoramento "deve ser ditada pelo perfil de risco do banco". Mapeie cada cenário de monitoramento de transações que o candidato executa para uma tipologia em sua avaliação de risco, e trate uma tipologia de alto risco não mapeada como uma lacuna, por mais limpos que pareçam os outros resultados.

Dados completos fazem parte da qualidade do alerta, porque uma plataforma não pode alertar sobre uma transação que nunca recebeu. Um oficial de PLD de uma fintech de pagamentos pré-pagos disse que parte do motivo para um novo processo de seleção foi o fato de o provedor atual não retornar os dados de transações que havia recebido. Com isso, após uma falha no envio, a equipe não conseguia confirmar se cada transação tinha sido processada. A equipe queria provas de que o provedor havia recebido cada linha, "não apenas de que a tarefa foi executada", e qualquer candidato deve ser capaz de conciliar o que processou com o que foi enviado, fluxo por fluxo.

Os auditores também analisam o volume de alertas dentro do contexto. O diretor de conformidade de uma subsidiária bancária disse que o regulador apontou que o banco gerava mais alertas do que bancos semelhantes de mesmo porte e volume. Alinhar o volume mantendo a cobertura de tipologias é uma disciplina de ajuste, detalhada em um guia para reduzir falsos positivos de PLD sem perder cobertura. Se as regras ou os modelos de aprendizado de máquina devem gerar os alertas é uma questão de design separada, abordada em um guia comparativo entre regras de monitoramento de transações e aprendizado de máquina.

O que significa o processo do investigador e para onde o tempo realmente vai

O processo do investigador é o caminho que vai de um alerta a uma decisão documentada: coleta de evidências, análise, redação da justificativa para encerramento ou escalação e, para alertas que se transformam em casos, a investigação mais profunda que precede a decisão de uma SAR. O manual do FFIEC trata a gestão de alertas como um componente próprio, focado nos "processos usados para investigar e avaliar atividades incomuns identificadas", e afirma que "os investigadores devem documentar as conclusões, incluindo qualquer recomendação sobre enviar ou não uma SAR".

A coleta consome grande parte do tempo do investigador antes mesmo de começar qualquer julgamento. Um gerente de TI em uma gestora de recursos observou os analistas trabalhando em um alerta e viu que o primeiro passo deles era sair da ferramenta de casos e fazer login em vários outros sistemas para buscar dados que ela não continha. Em um grande banco regional, um diretor e vice-presidente sênior de PLD e sanções chamou isso de "transporte crítico sem valor agregado", com investigadores "copiando e colando de suas notas e de suas planilhas favoritas". Do ponto de vista do investigador, um profissional sênior de BSA em um banco comunitário disse que o sistema "basicamente apenas repete e joga alertas para nós. E então eu jogo tudo em [uma planilha] e faço eu mesmo".

A análise e a redação são os outros grandes custos. Ao ser questionado sobre onde as horas são gastas, um subdiretor de PLD em um banco digital disse: "Acho que muito tempo é gasto na análise, bem como na redação das justificativas para encerramento ou escalação. E quando você chega ao nível do caso, é aí que vejo mais aquela alternância entre sistemas e pesquisas externas."

Meça para onde vai o tempo antes de desenhar o teste, pois a etapa mais lenta varia entre as instituições. Em uma fintech de pagamentos pré-pagos, um diretor de monitoramento de transações de PLD disse que a demora no lado do caso ocorre ao aguardar os clientes responderem aos contatos, acrescentando: "Sendo muito honesto, nossa operação é bastante ágil no lado dos alertas." Por outro lado, um vice-presidente e oficial de risco de PLD de um banco comunitário disse que o sistema atual já "preenche grande parte dessas informações" e "a única coisa que realmente nos toma tempo às vezes é fazer a análise". Uma plataforma que acelera uma etapa que sua equipe já resolveu não mudará seus resultados.

Pontue o tratamento de alertas e a investigação de casos separadamente no mesmo teste, já que uma plataforma pode ser rápida em um e lenta no outro. Um processo melhor também gera investigações melhores, como descreveu o diretor e vice-presidente sênior de PLD e sanções do grande banco regional: "Se você gastasse menos tempo no transporte e na consolidação de dados, talvez não estivesse apenas encontrando uma ótima SAR, mas descobrindo uma quadrilha, uma rede inteira." É por isso que o processo deve fazer parte da avaliação de detecção.

Por que a qualidade do alerta e o processo do investigador precisam ser testados juntos

A qualidade do alerta e o processo do investigador devem ser testados juntos porque cada um pode melhorar à custa do outro, e testes separados perdem essa relação de troca. Uma plataforma mais silenciosa, que gera menos alertas mas remove o contexto deles, pode atrasar cada investigação restante, enquanto uma mais ruidosa, cujos alertas chegam com evidências completas, pode encerrar mais casos, mais rápido e com melhores registros.

O contexto é o que torna um alerta tratável. Um alerta que apenas reporta que algo pareceu incomum não dá ao investigador elementos para agir; o que o cliente normalmente faz, o que está associado à conta e por que o alerta disparou é o que o torna acionável.

Apenas o caso encerrado mostra os dois lados dessa balança ao mesmo tempo.

Para pontuar casos encerrados, registre para cada alerta se ele chegou a uma decisão que você pudesse defender, quanto tempo isso levou e se ele deixou passar algo que seus analistas detectaram. O manual do FFIEC direciona os auditores da mesma forma: "Os auditores devem focar em se o banco possui um processo eficaz de tomada de decisão sobre SARs, não nas decisões individuais de SARs" e "Os bancos devem documentar as decisões de SARs, incluindo o motivo específico para enviar ou não uma SAR".

Uma divergência com uma decisão passada avalia tanto o registro quanto a plataforma. Alguns analistas terão encerrado ou escalado alertas com base em conhecimentos que nunca constaram no arquivo do caso, como o que o cliente comercial realmente faz ou atividades investigadas fora do sistema. Um candidato que lê apenas o arquivo discordará dessas decisões, e estará certo em relação ao arquivo. Vale a pena analisar cada divergência, mais do que a taxa de concordância geral, porque algumas são erros da plataforma, algumas são lacunas nos dados e algumas são práticas que ninguém documentou.

Deixe espaço para o julgamento do analista sobre atividades que nunca geraram alerta. O diretor de conformidade de PLD de um banco regional queria manter um recurso de revisão humana: revisores que notam atividades que nunca geraram alertas, mas que parecem suspeitas, e as encaminham para investigação. Um teste que conta apenas alertas não consegue identificar esses encaminhamentos, por isso registre-os durante a janela de avaliação.

Decida o que significa sucesso antes que os resultados cheguem e estruture-o em torno da qualidade. Em uma cooperativa de crédito, um gerente de BSA definiu a meta como "Mesmo que nossos números não diminuam... apenas faça com que tenham mais qualidade", porque "temos oportunidades para identificar atividades suspeitas adicionais que podem estar passando despercebidas atualmente". Uma métrica definida com antecedência não pode ser moldada para se ajustar à plataforma de preferência da equipe.

Como executar a avaliação com os seus próprios dados

Uma avaliação com os seus próprios dados é realizada em sete etapas, seja ela chamada de prova de conceito (POC), piloto ou teste comparativo, e cada etapa gera evidências que valem a pena guardar.

1. Defina o que significa sucesso por escrito antes de ver os resultados. Indique as métricas, o público e o patamar que o candidato deve atingir, e faça com que as pessoas que assinarão a decisão concordem com eles. Uma métrica escolhida depois tende a favorecer a plataforma que se saiu melhor.

2. Escolha um público que se pareça com o seu trabalho real. Pegue uma janela histórica com SARs conhecidas, alertas encerrados e encaminhamentos, e execute-a nos seus fluxos reais, com falhas inclusas. Um vice-presidente e gerente de grupo de direcionamento de risco em um grande banco foi sincero sobre essas falhas: "Você ficaria ou não surpreso com o quão terríveis são nossos dados, quão fragmentados e quantas conexões quebradas temos em nossos fluxos todos os dias." Uma plataforma testada com dados limpos diz muito pouco sobre fluxos reais como esses.

3. Faça um teste retrospectivo (backtest) da janela contra o seu sistema atual, em ambas as direções. Rode novamente os dados no candidato e coloque seus alertas ao lado dos gerados pelo seu sistema. Um líder de TI em uma instituição descreveu a versão de compra desse teste: "Acho que seria excelente ver algo que alertou em nosso outro sistema também alertar no seu e entender como eles resolvem isso." A verificação inversa, como descreveu um gerente de conformidade regulatória de uma empresa de auditoria de BSA e validação de modelos, consiste em confirmar "se o sistema antigo estava disparando os alertas corretos" e "garantir que o novo sistema não estivesse deixando passar nada".

4. Trabalhe uma amostra cega como novos alertas. Dê aos investigadores uma amostra de alertas do candidato sem a recomendação dele e faça com que trabalhem cada um deles da forma descrita por um líder de operações de PLD de uma empresa de pagamentos: "nós apenas trataríamos como um alerta novinho em folha, analisaríamos e olharíamos nossos dados". Compare os resultados com o que seus analistas decidiram na época ou, como colocou um diretor de BSA em um banco parceiro, "vamos olhar para os dados históricos e ver o que nossos analistas fizeram".

5. Monitore o fluxo em tempo real (shadowing) em paralelo com o processo existente. Execute o candidato com dados em tempo real enquanto seu sistema e equipe atuais continuam trabalhando normalmente, para que a comparação cubra atividades que a janela histórica não continha. Em sua declaração conjunta de 2018 sobre inovação, ainda em vigor em setembro de 2026, a FinCEN e os reguladores federais de bancos e cooperativas de crédito chamaram os programas-piloto de "um meio importante para testar e validar a eficácia de abordagens inovadoras" e disseram que os pilotos "não devem sujeitar os bancos a críticas de supervisão, mesmo que os programas-piloto acabem não tendo sucesso".

6. Analise cada divergência e pergunte o que o candidato deixou passar. Onde ele perdeu algo que sua equipe detectou, descubra o motivo antes de pontuar qualquer outra coisa. Onde ele levantou algo que seu sistema atual perdeu, olhe de perto antes de chamar de ruído: se seu sistema atual tem lacunas, usá-lo como única referência é um erro, e a diferença pode ser a grande descoberta. A pergunta que todo backtest deve enfrentar foi feita por um diretor de PLD de uma gestora de recursos: "Como nós sabemos?"

7. Teste o provedor tão bem quanto o produto. Um diretor de conformidade de PLD de uma operadora de jogos online considerou o suporte e a solidez do provedor como "um ponto adicional que precisa ser provado na POC, não apenas os agentes de IA". Um líder de tecnologia de uma empresa de tecnologia de folha de pagamento com um braço bancário alertou que, após a decisão, "passamos para a equipe de implementação deles, que às vezes no passado nos deixou bastante na mão". Conheça a equipe que implementará e dará suporte à plataforma, peça referências sobre a implementação e acompanhe a rapidez com que o provedor responde durante o teste.

Como definir o escopo, cronograma e aprovação para o exercício é abordado em um guia de critérios de aceitação para uma prova de conceito.

O que medir e como identificar um resultado fraco

As métricas que definem a avaliação de uma plataforma de PLD mostram a qualidade do alerta e o processo do investigador nos seus próprios casos. A tabela abaixo lista dez delas, com a forma de interpretá-las e como se parece um resultado fraco.

Um resultado fraco em qualquer linha é um ponto a ser resolvido antes da tomada de decisão.

A explicabilidade tem um peso especial porque o auditor testará isso diretamente. Em uma cooperativa de crédito, um gerente de conformidade de BSA/PLD/OFAC disse que, quando os reguladores perguntam como os alertas são gerados, a equipe não consegue mostrar as regras específicas, porque o provedor de monitoramento atual expõe apenas uma visão de alto nível. O manual do FFIEC prevê o oposto: "A gestão deve documentar e ser capaz de explicar os critérios de filtragem, os limites utilizados e como ambos são adequados aos riscos do banco."

Verifique o ambiente de teste também. Um executivo de BSA/PLD em um banco com operação digital descreveu a lacuna em seu sistema atual: "Se você quiser fazer algumas alterações nos limites das regras existentes, isso não é algo que você possa testar antes de ativar no sistema." O manual espera que os critérios de filtragem e limites sejam periodicamente revisados e testados "para garantir que continuem eficazes", o que é difícil em uma plataforma que só permite testar alterações diretamente em produção.

Independentemente das pontuações, registre tudo por escrito. Um líder de conformidade de BSA/PLD de um banco comunitário explicou o motivo, partindo da pergunta do auditor: "Como você determinou isso? Como o sistema determinou isso? E se eu não tiver isso por escrito, não poderei defender."

Como uma avaliação pode ser enganosa

Uma avaliação é enganosa quando mede a unidade errada ou roda com os dados errados. Estas são as formas mais comuns, todas abordadas acima:

• testar com dados limpos ou amostras genéricas em vez de usar seus fluxos reais

• pontuar alertas e ignorar casos encerrados, fazendo com que uma fila menor que atrasa investigações pareça uma vitória

• tratar a correspondência com seu sistema atual como sucesso, mesmo quando esse sistema tem lacunas conhecidas

• reportar uma taxa de concordância geral excelente e deixar as divergências sem análise

• escolher a métrica de sucesso depois de receber os resultados

• focar apenas na demonstração e nunca no dia a dia do investigador

• reunir-se apenas com a equipe de vendas e nunca com a equipe de implementação

O que guardar da avaliação para apresentar ao seu auditor

Guarde um registro da avaliação que qualquer pessoa de fora do projeto possa compreender: a base de dados testada e por que foi escolhida, o método, os resultados, como cada divergência foi interpretada e os motivos da escolha final. Esse registro responde ao auditor que questiona como a instituição escolheu sua plataforma de monitoramento e serve como base para a justificativa interna da decisão. Um líder de conformidade de BSA/PLD de um banco comunitário descreveu essa etapa interna como "o que chamamos de formulário de justificativa do projeto... que orienta você sobre os prós e contras... a análise de custo-benefício".

O modelo de um fornecedor ainda precisa ser validado pela própria instituição. As diretrizes revisadas de gestão de risco de modelos, emitidas em 17 de abril de 2026 pelo Federal Reserve (SR 26-2), o OCC (Bulletin 2026-13) e o FDIC (FIL-15-2026), substituíram as normas antigas e a declaração conjunta de 2021 sobre gestão de risco de modelos para sistemas BSA/PLD. O texto reconhece que os bancos "podem não receber do fornecedor o código, dados ou metodologia subjacentes" e afirma que "Um elemento importante da gestão de risco de modelos é a validação de produtos de fornecedores, seja por equipes internas ou externas." Peça a cada candidato a documentação que seus validadores precisarão e registre quais deles conseguiram fornecer.

Essa mesma diretriz "deve ser mais relevante para organizações bancárias com mais de US$ 30 bilhões em ativos totais" e deixa a IA generativa e os agentes de IA fora do seu escopo. Um guia separado aborda o que a validação de modelos de PLD envolve hoje, incluindo a profundidade ideal da validação de um modelo de monitoramento.

Instituições menores ainda enfrentam as expectativas do manual de auditoria para sistemas de monitoramento. O manual do FFIEC afirma que "a metodologia de programação e a eficácia do sistema de monitoramento devem ser validadas de forma independente", e essa expectativa não depende do tamanho dos ativos.

Um candidato que encontra atividades que seu sistema atual perdeu não coloca, por si só, seu programa atual em dúvida. A declaração conjunta de 2018 afirma que, quando os bancos testam o monitoramento de transações baseado em IA e encontram atividades suspeitas que seus processos existentes não teriam identificado, "as agências não presumirão automaticamente que os processos existentes dos bancos são deficientes". Registre essas descobertas e como foram tratadas como parte da avaliação.

A proposta de programa da FinCEN para 2026 trata da mesma preocupação. O preâmbulo de sua proposta de regra de programa de PLD/CFT (91 FR 18704, abril de 2026) afirma que as instituições que experimentam tecnologias inovadoras de forma responsável "não incorrerão em nenhum risco adicional de serem sujeitas a ações de supervisão ou execução de PLD/CFT baseadas exclusivamente no uso de tecnologias inovadoras". Até setembro de 2026, a regra do programa da FinCEN ainda é uma proposta: o período para comentários encerrou em 9 de junho de 2026, e nenhuma regra final foi emitida.

Adicionar uma nova plataforma sobre seu sistema atual ou substituí-lo?

Uma nova plataforma pode valer a pena mesmo sem substituir seu sistema atual, e uma sobreposição (overlay) deve passar pelo mesmo teste que uma substituição integral. Uma camada que recebe alertas do seu monitoramento existente e os prepara para os investigadores ainda precisa provar, com os seus dados, que as decisões se tornam mais rápidas e defensáveis, sem deixar passar nada do que sua equipe identificaria. A comparação muda de figura: a sobreposição é medida em relação ao seu processo atual sobre os mesmos alertas, enquanto a substituição é avaliada como um motor de detecção contra o outro.

A responsabilidade final permanece com a instituição em qualquer um dos caminhos. Fazer a transição em etapas, mantendo as fontes de dados de origem e o sistema atual ativos enquanto adiciona uma nova camada, é uma decisão de modernização por si só. O que acontece após a escolha, incluindo a migração de dados, a execução paralela de uma migração, a validação e a comunicação com os auditores, é abordado em um guia de compras de software de PLD separado.

Como a Oscilar aborda uma avaliação

A Oscilar estrutura uma avaliação pré-produção como uma parceria de design em quatro etapas: configuração de dados, teste retrospectivo (backtest) contra os alertas históricos da instituição, modo paralelo (shadow mode) junto com o processo existente e uma apresentação com validação humana (human-in-the-loop). Essas etapas seguem o teste descrito neste guia, utilizando os dados da própria instituição. A plataforma oferece suporte a backtests, testes A/B e testes unitários para validar modelos de risco existentes e novos, permitindo que alterações de limites ou cenários sejam testadas em dados históricos antes de entrarem em produção.

Após a ativação, a Oscilar monitora desvios de dados, de recursos e de conceitos (drift), juntamente com KPIs de resultados segmentados. A plataforma mantém uma trilha de auditoria completa por decisão com justificativas armazenadas, sendo estruturada com o conceito "human-in-the-loop" (humano no circuito): os agentes de IA nunca encerram ou escalam um alerta sozinhos, e um analista humano revisa e confirma cada recomendação antes que qualquer ação seja tomada. A instituição preserva seus padrões de validação, autoridade de aprovação e responsabilidade regulatória.

A métrica defendida neste guia é a mesma que a Oscilar reporta em suas implementações. Um banco em produção apresenta 92% de concordância dos analistas com a equipe humana sobre a decisão dos alertas e 75% de redução no tempo gasto por revisão. A concordância com os próprios analistas do banco é a metade correspondente à qualidade do teste, e o tempo por revisão é a metade correspondente ao processo. Esses são os resultados de um banco específico em seus próprios alertas; os números com os quais sua instituição poderá contar serão aqueles gerados pela sua própria avaliação.

A Chartis Research incluiu a Oscilar no ranking FCC50 de 2026, com prêmios de categoria para Inovação em IA Agente e Customização Low-Code/No-Code. Esse reconhecimento aplica critérios de terceiros, mas o teste decisivo para a sua escolha ainda será aquele que você realizar com os seus próprios dados.

Perguntas frequentes

Como uma instituição financeira deve comparar plataformas de monitoramento de transações de PLD?

Uma instituição financeira deve comparar plataformas de monitoramento de transações de PLD testando cada uma com seus próprios dados históricos e em tempo real, em vez de se basear em listas de funcionalidades ou demonstrações. O teste avalia casos encerrados: se cada alerta levou a uma decisão defensável, quanto tempo isso demorou e o que a plataforma deixou passar que os analistas da instituição detectaram. As decisões anteriores dos analistas são a referência, e o registro do teste deve ser guardado para os auditores.

Por que testar a qualidade do alerta e o processo do investigador juntos?

Testar a qualidade do alerta e o processo do investigador de forma conjunta é fundamental porque a melhoria de um aspecto pode prejudicar o outro. Uma plataforma que reduz o volume de alertas, mas retira o contexto de cada um, pode atrasar todas as investigações restantes. Por outro lado, uma fila que roda mais rápido pode deixar passar atividades suspeitas que os analistas detectariam. Avaliar o caso encerrado — ou seja, uma decisão defensável e o tempo gasto para alcançá-la — une as duas pontas em uma única métrica.

Como uma nova plataforma pode reduzir a revisão manual sem perder a aprovação humana final?

Uma nova plataforma reduz a revisão manual coletando as evidências necessárias para cada alerta e gerando uma recomendação prévia, mas o investigador continua revisando e confirmando cada decisão antes que qualquer ação seja tomada. O tempo economizado vem da redução de pesquisas e cópias entre sistemas, mantendo a pessoa responsável pela aprovação final ativa no processo. Uma avaliação deve confirmar que essa economia realmente se reflete nos casos encerrados e que cada decisão ainda traz a justificativa do investigador.

Quais evidências, testes e trilhas de auditoria os reguladores e compradores devem esperar de uma avaliação?

Reguladores e compradores devem esperar que a avaliação gere um registro por escrito da amostra testada, do método, dos resultados, de como cada divergência com uma decisão anterior foi analisada e por que a plataforma foi escolhida. Os testes devem incluir um backtest em dados históricos com SARs conhecidas, uma amostra cega analisada por investigadores e um período em paralelo com dados reais. A trilha de auditoria de cada alerta deve mostrar o que o gerou, quais dados o investigador viu, o que foi decidido, por quem e por quê. O modelo de um fornecedor ainda precisa de validação, seja pela instituição ou por terceiros.

Podemos avaliar uma nova plataforma enquanto a antiga continua funcionando?

Sim. A plataforma candidata pode rodar em paralelo (shadow mode) com dados em tempo real ao lado do sistema existente, que continua gerando os alertas tratados pela instituição. A declaração conjunta das agências reguladoras de 2018 sobre inovação, ainda em vigor em setembro de 2026, define os programas-piloto como "um meio importante de testar e validar a eficácia de abordagens inovadoras" e afirma que as agências não presumirão automaticamente falhas nos processos atuais caso um sistema baseado em IA encontre atividades que esses processos deixaram passar.

A melhor plataforma de monitoramento de transações de PLD para a sua instituição é aquela que demonstrou, com seus alertas e frente às decisões de seus analistas, que encerra casos com mais rapidez e melhor fundamentação, mantendo a cobertura de tipologias intacta. Comece definindo o sucesso por escrito, teste a qualidade e o processo de forma unificada e guarde o registro das suas escolhas. Para entender como a Oscilar pode atuar sobre o seu monitoramento existente ou substituí-lo com o tempo, conheça nosso material sobre modernização do monitoramento de PLD em etapas.