Última atualização: Outubro de 2026
O melhor software de AML (Anti-Lavagem de Dinheiro) para um banco, cooperativa de crédito ou fintech é aquele que cobre o risco de lavagem de dinheiro da própria instituição, oferece a mesma visão do cliente para todas as partes do programa e deixa um histórico que o auditor possa acompanhar desde o alerta até a decisão do SAR (Relatório de Atividade Suspeita). Nenhuma lista pré-definida pode prever isso. Por isso, este guia traz nove critérios claros, cada um com uma pergunta a ser feita e uma forma de testar a resposta com os seus próprios dados. A Oscilar escreveu este guia e vende software de AML. Por esse motivo, ela não cita nem classifica nenhum produto, além de se submeter aos mesmos nove critérios no final do texto.
Resumo Geral
O software de AML envolve quatro funções, não apenas um produto: due diligence e classificação de risco do cliente, monitoramento de transações, triagem de sanções e PEP (Pessoas Politicamente Expostas), e gestão de casos e envio de SAR.
Decida primeiro se você quer essas funções em uma única plataforma ou distribuídas em várias ferramentas, e seja realista sobre os custos e perdas na transição de dados entre elas.
Avalie cada provedor com base nos mesmos nove critérios, desde a cobertura do seu próprio risco até a validação independente e a aprovação humana em qualquer recomendação feita por IA.
Trate respostas vagas como um sinal de fraqueza e teste os provedores selecionados com os seus próprios dados antes de fechar o contrato.
A resposta direta: como escolher um software de AML
Para escolher um software de AML, comece pela sua própria avaliação de risco em vez de uma lista de funcionalidades. Decida para qual das quatro funções de AML você está comprando e faça as mesmas perguntas a todos os provedores com base em critérios definidos. O Manual de Exame FFIEC BSA/AML estabelece o princípio para o monitoramento: "A sofisticação dos sistemas de monitoramento deve ser ditada pelo perfil de risco do banco." Os provedores que apresentarem respostas consistentes formarão uma lista final para testes com seus dados históricos e em tempo real antes de assinar o contrato.
Definir critérios claros é essencial, pois as primeiras conversas costumam parecer muito parecidas. Um diretor de conformidade de um banco médio descreveu o início de uma avaliação da seguinte forma: "no começo, o discurso de todo mundo parece igual, mas o que importa é: o que a ferramenta realmente faz? Quais são os resultados?" Os nove critérios abaixo foram criados para responder a essas duas perguntas para qualquer provedor.
Este guia aborda como montar a sua lista de finalistas. Uma vez definida a escolha, as etapas seguintes de compra e migração do software de AML — desde a transferência do histórico até o período de teste em paralelo e a virada de chave — são explicadas em um guia à parte.
O que o software de AML abrange
O software de AML é o conjunto de sistemas que uma instituição financeira usa para conhecer seus clientes, monitorar suas atividades, cruzá-los com listas de sanções e pessoas politicamente expostas (PEP), além de investigar e reportar o que parecer suspeito. A maioria dos softwares de prevenção à lavagem de dinheiro faz bem uma ou duas dessas funções, e algumas plataformas tentam cobrir as quatro. Cada etapa gera um registro que será analisado por um auditor, e é por isso que o histórico gerado é tão importante quanto a detecção em si.
Componente | O que faz | O registro gerado |
|---|---|---|
Due diligence e classificação de risco do cliente | Identifica e verifica clientes e beneficiários finais, classificando o risco de cada um | Registros de identificação e verificação, além de uma classificação de risco com suas justificativas |
Monitoramento de transações | Acompanha a atividade do cliente ao longo do tempo e gera alertas para comportamentos incomuns | Cada alerta, a versão da regra ou modelo que o disparou e os dados analisados |
Triagem de sanções e PEP | Cruza clientes e pagamentos com listas de sanções e PEP, enviando as ocorrências para revisão | Cada ocorrência identificada, como foi tratada e por quem |
Gestão de casos e envio de SAR | Agrupa alertas e ocorrências em investigações e registra a decisão de enviar ou não o relatório (SAR) | O arquivo do caso, a decisão do SAR com sua justificativa e o envio do documento |
Cada componente está associado a um conjunto de regras ou diretrizes. Para a due diligence do cliente, a norma de CDD da FinCEN (31 CFR 1010.230) exige que a instituição identifique cada pessoa física que "possua 25% ou mais das participações societárias" de um cliente pessoa jurídica, e verifique os beneficiários finais "de acordo com processos baseados em risco, na medida do que for razoável e viável". A classificação de risco do cliente baseia-se nesse trabalho, e um analista de conformidade de um banco comunitário explicou de forma simples a sua importância: "a gestão de risco do cliente é um pilar essencial do programa de AML".
Do lado do monitoramento, o manual do FFIEC descreve cinco etapas interdependentes para o acompanhamento e reporte de atividades suspeitas: identificação ou alerta de atividade incomum, gestão de alertas, tomada de decisão sobre o SAR, preenchimento e envio do SAR, e monitoramento contínuo com novos reportes. Softwares de monitoramento que apenas geram alertas cobrem apenas a primeira dessas etapas. Os nove critérios para software de monitoramento de transações detalham melhor essa função específica.
A triagem é apenas um dos controles dentro de um programa mais amplo. O Framework de Compromissos de Conformidade do OFAC de 2019 cita cinco componentes essenciais: "(1) comprometimento da gestão; (2) avaliação de risco; (3) controles internos; (4) testes e auditoria; e (5) treinamento." Uma ferramenta de triagem faz parte dos controles internos, e o Framework espera que a instituição tenha "selecionado e calibrado as soluções de forma adequada para o perfil de risco e necessidades de conformidade da organização". Como avaliar uma ferramenta de triagem por si só é tema de outro guia específico para a escolha de softwares de triagem de sanções.
A gestão de casos e o envio de SAR fecham o ciclo. O manual do FFIEC é claro sobre o que os auditores avaliam: "Os auditores devem focar em saber se o banco tem um processo de tomada de decisão de SAR eficaz, e não em decisões individuais de SAR." Também destaca que "Os bancos devem documentar as decisões de SAR, incluindo o motivo específico para enviar ou não o relatório."
Uma única plataforma ou várias ferramentas?
O software de AML pode ser adquirido como uma única plataforma que cobre as quatro funções ou como ferramentas independentes para cada uma delas — e ambas as escolhas podem estar corretas. O ponto de decisão é avaliar onde as transições de informações entre as ferramentas custam mais tempo, contexto ou segurança para a sua equipe. Uma boa avaliação analisa as duas opções antes de decidir.
A vantagem de usar uma única plataforma começa com a facilidade de encaminhamento dos casos. Um diretor de conformidade de um banco comunitário explicou por que preferia que o trabalho de prevenção a fraudes e conformidade ficasse integrado: "Prefiro que tudo funcione sob o mesmo teto porque, hoje, eles resolvem o alerta. Mas se não conseguem resolver, precisam escalar o caso... Se tivermos dois sistemas separados, essa integração simplesmente não vai existir". Um vice-presidente de operações de conformidade em outro banco comunitário descreveu o objetivo como unificar processos dispersos "desde a abertura da conta até todo o ciclo de vida do cliente".
Por outro lado, o argumento contra assumir que uma única plataforma faz tudo perfeitamente também é muito válido. Um diretor de conformidade de uma empresa de pagamentos comentou: "Ainda não vi um único fornecedor que faça tudo muito bem. Geralmente, um é excelente em monitoramento de transações (KYT), e outros são melhores em análise cadastral (KYB/KYC)". Uma ferramenta especializada pode ser a melhor escolha para um componente específico, desde que os dados gerados cheguem ao restante do programa sem perder o contexto.
A triagem de sanções costuma ser o fator decisivo nessa escolha. Um líder de conformidade que coordenou uma avaliação em um banco comunitário relatou que "o banco preferia uma solução mais consolidada que atendesse tanto ao monitoramento de AML quanto à triagem de sanções." Esse mesmo profissional listou o que uma ferramenta separada traz de complexidade: "risco adicional de gestão de fornecedores e dependência de terceiros, maior complexidade de implementação e esforço de integração".
Outros compradores preferem seguir o caminho oposto e manter sua ferramenta de triagem atual. Um vice-presidente de prevenção a fraudes e conformidade de uma cooperativa de crédito perguntou se a plataforma avaliada poderia receber as ocorrências identificadas pela ferramenta de triagem existente (inclusive as já descartadas) para dar sequência ao processo de AML, em vez de substituí-la.
Antes de comparar as plataformas, pergunte o que cada uma delas realmente recebe como entrada e o que entrega como resultado. Um diretor de conformidade de uma empresa de remessas em estágio inicial resumiu bem a questão: "Você está processando todo o fluxo de transações e devolvendo as ocorrências suspeitas? Ou está recebendo apenas os nossos alertas prévios e oferecendo um painel visual? São dois produtos completamente diferentes." Uma lista de finalistas que misture esses dois tipos de solução trará respostas impossíveis de comparar de forma justa.
Independentemente do modelo escolhido, unifique as informações e mantenha as responsabilidades separadas. As equipes de fraude e AML devem olhar para o mesmo cliente e comportamento, mas respondem a obrigações, reguladores e padrões de prova diferentes. Por isso, uma fila única de decisões misturadas pode gerar problemas de governança. Para uma fintech, o banco parceiro também faz parte dessa dinâmica: um diretor de risco e operações de uma fintech que opera via banco parceiro observou que o banco é o responsável final pelo reporte de SAR, o que limita o que a fintech pode consolidar por conta própria. A migração para uma única plataforma também pode ser feita por etapas, mantendo os sistemas atuais enquanto uma nova camada é integrada.
1. Cobertura do seu próprio risco
O que é. A cobertura de risco indica o quanto a lógica de detecção, triagem e classificação do software se alinha aos riscos reais da sua instituição: seus produtos, clientes, canais e regiões de atuação. O manual do FFIEC destaca que o monitoramento deve ser guiado pelo perfil de risco do banco, "com foco especial na composição de produtos, serviços, clientes e regiões de maior risco." Essa cobertura também exige segmentação, pois um banco parceiro, um banco com múltiplos segmentos de negócio ou uma fintech com produtos distintos raramente possuem um único perfil de risco.
Um diretor de conformidade de um banco comunitário questionou exatamente isso em uma demonstração: "Se tivermos um código de agência diferente para uma fintech que estamos apoiando, é possível definir um conjunto de regras exclusivo para as transações dessa agência específica?"
O que perguntar ao provedor. Mostre como a sua lógica de detecção se aplica aos nossos cenários de risco mais comuns e como podemos rodar regras diferentes para uma linha de negócio ou programa parceiro específico.
Como é uma resposta fraca. Apresentar apenas uma lista genérica de regras prontas, sem qualquer relação com a sua avaliação de risco e sem formas de tratar segmentos de clientes de maneira diferente.
Como testar com seus próprios dados. Pegue os cenários de risco mais comuns da sua operação e peça para o provedor mostrar, usando uma amostra das suas transações reais, qual regra ou modelo identificaria cada caso, e onde o sistema não teria cobertura alguma.
2. Classificação de risco do cliente sempre atualizada
O que é. A classificação de risco é a nota ou faixa que indica ao restante do programa o nível de atenção que deve ser dedicado a cada cliente. Ela precisa ser dinâmica, atualizando-se sempre que o comportamento ou os dados do cliente mudarem. Essa classificação orienta os limites de monitoramento, a frequência de triagem e os processos de due diligence reforçada (EDD). Portanto, um indicador desatualizado prejudica todo o sistema. Além disso, ela precisa ser justificável, pois o auditor perguntará os motivos de um cliente estar em determinada faixa de risco.
A equipe de conformidade de um banco comunitário descreveu as dificuldades com um sistema de pontuação estático: o sistema recalculava o risco dos clientes apenas uma vez por mês. A lista de clientes de alto risco mudava constantemente, e a equipe precisava controlar os prazos de due diligence e monitoramento manualmente em planilhas para conseguir apresentar um relatório organizado aos auditores.
O que perguntar ao provedor. Quais eventos alteram a classificação de um cliente entre as revisões periódicas, em quanto tempo essa alteração reflete no monitoramento e triagem, e qual justificativa é registrada em cada mudança?
Como é uma resposta fraca. Uma pontuação gerada em lotes periódicos que ninguém sabe explicar como funciona, exigindo o controle manual de prazos e listas de alto risco fora do sistema.
Como testar com seus próprios dados. Escolha uma amostra de clientes e simule um evento que deveria aumentar o risco deles (como a contratação de um produto de alto risco ou um padrão incomum de transações) para verificar se o sistema altera a nota, registra o motivo e atualiza os outros módulos automaticamente.
3. Seus dados de origem e livre acesso a eles
O que é. O acesso a dados refere-se à capacidade do software de ler informações do seu sistema bancário central e de outras ferramentas, quem realiza a integração dessas informações e se você consegue extrair todos os seus dados quando precisar. Todos os módulos dependem disso: a classificação de risco, um alerta ou uma triagem só serão eficazes se os dados cadastrais do cliente estiverem corretos. Um diretor de estratégia de fraude de um banco médio perguntou se o provedor já havia trabalhado com o sistema bancário que eles utilizavam, pois ter uma visão única do cliente depende de consolidar dados de vários sistemas diferentes dentro desse núcleo.
Poder exportar os dados é tão importante quanto importá-los. Um diretor de conformidade de uma fintech de cartões pré-pagos comentou: "Eu só preciso que todos os dados possam ser exportados de alguma forma, entende? Só preciso de uma janela de acesso aberto aos dados".
O que perguntar ao provedor. Com quais dos nossos sistemas atuais vocês conseguem se conectar desde o primeiro dia, quem faz essa integração e nós podemos exportar todos os registros, incluindo alertas, decisões e histórico de casos?
Como é uma resposta fraca. Oferecer relatórios fixos em vez de uma exportação completa de dados, ou propor um projeto de integração cujo custo e escopo só são definidos após a assinatura do contrato.
Como testar com seus próprios dados. Solicite a extração completa de um mês de testes — incluindo alertas, decisões e notas de análise — e cruze os dados com o que os seus sistemas atuais registraram para o mesmo período.
4. Um processo único do alerta à decisão final de SAR
O que é. O fluxo do alerta ao SAR é o caminho que uma atividade incomum percorre desde o disparo do alerta inicial, passando pela investigação do caso, até a decisão formalizada de enviar ou não o relatório de atividade suspeita (SAR). O manual do FFIEC trata a gestão de alertas como uma etapa essencial: "A gestão de alertas foca nos processos usados para investigar e avaliar as atividades incomuns identificadas." Ele complementa que "os analistas devem documentar suas conclusões, incluindo qualquer recomendação sobre enviar ou não o SAR."
Esse fluxo começa com um alerta rico em contexto. Dizer apenas que algo foi incomum não ajuda na análise; o que torna o alerta útil é o contexto associado, como o comportamento habitual da conta e outras relações financeiras do cliente. A partir daí, a gestão de casos centraliza a investigação mais profunda: conectando alertas e envolvidos, reunindo provas, registrando justificativas e organizando as aprovações necessárias.
O envio do relatório deve fazer parte desse mesmo fluxo de trabalho. Um diretor de conformidade de um banco comunitário listou o que uma demonstração de produto precisa mostrar: "Consigo enviar os relatórios de SAR? E de transações em espécie (CTR)? ... Consigo resolver tudo pela plataforma ou preciso acessar outro sistema para concluir? No dia a dia, isso faz toda a diferença".
O que perguntar ao provedor. Mostre como um alerta se transforma em um caso de investigação, como conectar dois alertas relacionados em uma única análise e como registrar uma decisão de SAR com sua justificativa (inclusive no caso de não envio).
Como é uma resposta fraca. Controle de casos fora do sistema. Um diretor de conformidade de uma empresa de pagamentos relatou trabalhar com uma equipe que não tinha uma ferramenta central de gestão de casos, precisando buscar dados em vários sistemas, redigir decisões em anotações soltas e controlar tudo por planilhas.
Como testar com seus próprios dados. Simule um caso real já encerrado do seu histórico, desde o alerta inicial até a decisão do SAR, e confirme se todas as etapas e justificativas ficam registradas em uma única tela.
5. Regras fáceis de alterar pela sua equipe, com histórico de modificações
O que é. Controle de alterações é definir quem pode modificar as regras e limites de detecção, como essas alterações são testadas antes de irem para o ambiente real e como os motivos, testes e aprovações são registrados. Um diretor de conformidade de um banco comunitário explicou como faz esse registro hoje de forma manual: "Precisamos documentar o motivo da alteração, apresentar os resultados dos testes e enviar para a aprovação de outra pessoa". Um bom software faz esse registro de forma automática para você.
Os compradores preferem que os próprios analistas de conformidade façam essas alterações, sem depender de desenvolvedores. Um diretor de risco de uma fintech que opera com bancos parceiros buscava uma solução para que "profissionais de negócio, como meus analistas, pudessem criar regras e alertas rapidamente no dia a dia". Quando toda alteração depende da equipe de TI, como observou um analista de KYC de um banco digital, "não há como fazer ajustes rápidos".
O teste antes da publicação é a outra metade do desafio. Um diretor de conformidade de uma fintech de cartões pré-pagos descreveu a demora para ajustar regras: "Precisamos esperar o fechamento do processamento mensal para ver o resultado prático de uma regra... se você colocar 'maior que' em vez de 'maior ou igual a', o resultado muda e você precisa esperar um mês inteiro para perceber o erro". Um diretor de conformidade de outro banco lembrou de uma mudança de regra em sua experiência anterior que gerou uma avalanche de alertas indevidos, reforçando a importância de um ambiente de testes.
O que perguntar ao provedor. Nossos analistas conseguem alterar uma regra sem depender de suporte técnico ou chamados pagos, testá-la com nosso histórico no mesmo dia e registrar quem aprovou a mudança e por quê?
Como é uma resposta fraca. Alterações de regras que dependem de abertura de chamados com o provedor, ou mudanças cujo impacto você só descobre depois que o próximo ciclo de monitoramento rodar.
Como testar com seus próprios dados. Faça uma alteração real de parâmetro durante o período de testes, simule o impacto no seu histórico no mesmo dia e confirme se o registro de auditoria mostra o motivo, o resultado do teste e quem autorizou. Um analista de conformidade de um banco comunitário resumiu a exigência: "para fins de auditoria e conformidade, precisamos de rastreabilidade total de todas as alterações feitas no sistema."
6. Justificativas fáceis de explicar para um auditor
O que é. Explicabilidade significa que todo alerta, classificação de risco e decisão pode ser detalhado por escrito, meses depois, para alguém que não participou do processo. O manual do FFIEC destaca: "A gestão deve documentar e ser capaz de explicar os critérios de filtragem, os parâmetros utilizados e por que eles são adequados aos riscos do banco." Um diretor de conformidade de um banco comunitário resumiu o cenário de fiscalização: "o auditor vai me perguntar como o sistema chegou àquela conclusão. Se eu não tiver isso registrado, não terei como defender nossa decisão."
Essa explicação precisa cobrir tanto o momento atual quanto o histórico de alterações. Um gestor de conformidade de uma cooperativa de crédito explicou: "Preciso ter argumentos sólidos para explicar como nosso sistema gera os alertas e, caso tenhamos feito alterações no período, provar que essas mudanças foram feitas com critérios consistentes". Um registro robusto para auditoria deve mostrar o alerta, a versão exata da regra ou modelo que o disparou, os dados que o analista visualizou na época, as provas coletadas, a recomendação inicial, a decisão final do analista e quem validou a ação.
O que perguntar ao provedor. Acesse uma decisão tomada há alguns meses e nos mostre o motivo da resolução, qual versão da regra estava ativa na data, quais dados o analista visualizou e quem foi o responsável pela aprovação.
Como é uma resposta fraca. Apresentar uma nota de risco sem justificativas associadas ou depender do suporte técnico do próprio fornecedor para puxar esse histórico de decisões.
Como testar com seus próprios dados. Durante os testes, selecione alguns alertas aleatórios e peça para um profissional que não participou daquela análise tentar explicar o caso para um auditor usando apenas as informações registradas pelo sistema.
7. O sistema permite validação por especialistas independentes?
O que é. A validação independente é uma revisão detalhada — feita por equipes internas de auditoria ou consultorias externas que não participaram do desenvolvimento do sistema — para garantir que a lógica de detecção funciona conforme documentado. O manual do FFIEC orienta que "a metodologia de programação do sistema de monitoramento e sua eficácia devem ser validadas de forma independente para garantir que os modelos detectem atividades potencialmente suspeitas." Isso exige que o provedor ofereça aos validadores acesso à lógica, documentação técnica e ferramentas de teste com seus dados.
As diretrizes de gestão de risco de modelos foram atualizadas recentemente. Em 17 de abril de 2026, o Federal Reserve, OCC e FDIC publicaram novas orientações (SR 26-2, OCC Bulletin 2026-13 e FDIC FIL-15-2026), substituindo as normas anteriores. Sobre sistemas contratados de terceiros, o documento destaca que as instituições "podem não ter acesso ao código-fonte, dados ou metodologia do fornecedor... Mesmo assim, os princípios de gestão de risco de modelos continuam aplicáveis."
Três detalhes da nova diretriz ajudam a planejar essa validação. Processos baseados apenas em regras estáticas (sem teorias estatísticas ou financeiras de comportamento) não entram na definição estrita de "modelo", o que significa que pontuações estatísticas e de aprendizado de máquina precisam de validação formal, enquanto regras simples podem ser isentas. Essa diretriz é mais recomendada para instituições com ativos acima de US$ 30 bilhões e não define obrigações rígidas. Além disso, sistemas de inteligência artificial generativa e agentes ficam de fora do escopo inicial de modelos, devendo ser acompanhados pelas práticas gerais de gestão de risco de cada instituição.
O que perguntar ao provedor. Quais documentos técnicos, dados e ferramentas de teste os nossos validadores receberão para analisar cada modelo e conjunto de regras, e como cada modelo é monitorado após entrar em produção?
Como é uma resposta fraca. Tratar a metodologia como segredo comercial ou propriedade industrial, sem oferecer documentação alternativa para auditoria.
Como testar com seus próprios dados. Peça para o seu auditor ou empresa de validação analisar a documentação técnica oferecida pelo fornecedor durante o período de testes e realizar uma validação preliminar com seus dados. O processo de validação durante a troca de sistemas é abordado no guia de contratação citado anteriormente.
8. Validação humana em todo uso de Inteligência Artificial
O que é. Validação humana significa garantir que, sempre que o sistema utilizar inteligência artificial — seja para analisar alertas ou sugerir textos de justificativas —, a decisão final seja tomada por uma pessoa, com registro claro de quem foi o responsável. A IA pode analisar dados, organizar provas e sugerir decisões, mas o fechamento do alerta ou o envio do SAR deve ser sempre de responsabilidade do analista. Um diretor de conformidade de um banco comunitário resumiu a visão regulatória: "Acredito que os reguladores ainda não aceitam decisões totalmente automáticas tomadas por sistemas de IA".
O que perguntar ao provedor. Em qual etapa de cada processo o analista valida a recomendação feita pela IA, e como o sistema registra a sugestão da máquina, a justificativa apresentada e o profissional que aprovou a ação?
Como é uma resposta fraca. Sistemas de IA que fecham alertas de forma 100% automatizada, ou relatórios que não conseguem separar o que foi sugerido pelo algoritmo do que foi decidido pelo analista humano.
Como testar com seus próprios dados. Rode as recomendações da IA em paralelo com as análises da sua equipe para o mesmo conjunto de alertas, compare as decisões e verifique se nenhum caso de teste foi fechado ou escalado sem a devida autorização humana registrada.
9. Um teste prático com seus dados reais
O que é. Um teste prático consiste em rodar a nova ferramenta com o seu histórico de dados e, em seguida, em paralelo com o seu sistema atual antes de assinar o contrato final. Um diretor de conformidade de um banco comunitário explicou a relevância: "Um projeto piloto (POC) é essencial porque é onde você trabalha com a realidade dos seus dados". A declaração conjunta dos órgãos reguladores de 2018 sobre inovação no combate à lavagem de dinheiro destaca que projetos-piloto "são meios importantes para testar e validar a eficácia de novas tecnologias" e "não devem expor os bancos a críticas das autoridades supervisoras, mesmo que os testes não tragam os resultados esperados."
Confirme o que o provedor chama de "modo piloto em paralelo" para não ter surpresas. Um analista de conformidade de uma fintech perguntou em uma avaliação: "Trata-se de um teste em paralelo real, onde podemos ver o impacto das regras nas transações do dia a dia, ou é apenas um ambiente de testes estático onde precisamos subir arquivos de dados manualmente?"
O que perguntar ao provedor. Vocês realizam o teste com nossos alertas históricos e depois rodam o sistema em paralelo com nossa operação real, mostrando tanto o que o sistema detectou quanto o que ele eventualmente deixou passar? Quais órgãos reguladores ou auditores já avaliaram o funcionamento do sistema de vocês? Como disse um gerente de conformidade de uma cooperativa de crédito: "Tenho interesse em saber com quais auditores e órgãos de fiscalização vocês já trabalharam."
Como é uma resposta fraca. Apresentar apenas demonstrações com dados fictícios do próprio fornecedor, exigir carga manual de dados em um ambiente de homologação limitado ou apresentar resultados apenas em formato consolidado/resumido.
Como testar com seus próprios dados. Comece testando com dados históricos, depois rode em paralelo com a operação real e compare as decisões caso a caso com a sua equipe de analistas. O roteiro detalhado para avaliar plataformas de monitoramento de AML com seus próprios dados está disponível em um guia específico.
Onde a Oscilar se encaixa, avaliada pelos mesmos critérios
A Oscilar oferece uma plataforma unificada para decisões de risco que integra cadastro (onboarding), crédito, prevenção a fraudes e AML. Portanto, deve ser avaliada com base nos mesmos nove critérios aplicados a qualquer outro fornecedor. Esta seção baseia-se exclusivamente nas informações públicas e recursos validados da Oscilar, indicando também onde ela utiliza integrações de terceiros. Use este descritivo como ponto de partida para suas próprias avaliações, não como uma decisão final.
O que a Oscilar cobre. A Oscilar oferece uma plataforma integrada: conexão de dados em tempo real, inteligência de dispositivos e comportamento, regras de decisão e gestão de casos no mesmo ecossistema, com agentes inteligentes nativos. Esses agentes podem atuar de forma integrada na plataforma ou como uma camada adicional sobre os seus sistemas atuais, o que permite uma migração gradual em vez de uma substituição completa e imediata. Para detecção, a solução de AML para bancos da Oscilar combina regras personalizáveis com análises de comportamento, identificação de anomalias, risco do cliente, conexões de rede e priorização de alertas (critérios 1 e 2).
Triagem de Sanções. A Oscilar não atua diretamente como o motor de busca e correspondência de listas de sanções. As ocorrências de sanções são geradas por ferramentas especialistas integradas, e a Central de Agentes da Oscilar oferece um assistente de triagem que disponibiliza "Orientações detalhadas e justificativas pré-preenchidas para análise de cada ocorrência identificada." Compradores que buscam processamento nativo de listas e busca fonética de nomes na mesma plataforma devem avaliar esse ponto de acordo com a análise de plataforma única ou integrada detalhada anteriormente.
Alertas, casos e SAR (critério 4). A gestão de casos da Oscilar conecta alertas e pessoas relacionadas, organiza provas, armazena as justificativas e aprovações, e a área de AML para bancos conta com ferramentas para preenchimento automático e envio eletrônico de SARs diretamente para a FinCEN.
Alterações, explicações e validação (critérios 5 a 7). A Oscilar oferece suporte a testes retrospectivos (backtests), testes A/B e testes de regras em processos de risco, além de manter um histórico de auditoria completo para cada decisão com as respectivas justificativas, mantendo a validação humana integrada ao processo por definição. O sistema monitora desvios de padrões de dados e comportamento junto com indicadores de desempenho por segmento de clientes. Toda a arquitetura foi planejada para atender às diretrizes de auditoria e conformidade de modelos. A documentação da Oscilar reforça os limites de atuação: "O banco continua sendo o responsável final pelos padrões de validação, aprovações e conformidade regulatória."
Aprovação humana (critério 8). A Central de Agentes da Oscilar destaca: "Os agentes automatizados nunca fecham ou escalam alertas sozinhos — toda recomendação do sistema é revisada e confirmada por um analista antes de qualquer ação ser tomada."
Teste prático (critério 9). A Oscilar organiza as avaliações de contratação por meio de uma parceria de projeto de quatro semanas, que inclui estruturação de dados, testes retrospectivos com alertas históricos, operação em paralelo com o sistema atual e apresentação detalhada dos resultados. Casos de uso mostram até 92% de concordância entre as recomendações do agente inteligente e as decisões finais dos analistas, além de redução de até 75% no tempo médio de análise de casos.
Dados de origem e exportação (critério 3). Esse ponto depende da arquitetura de sistemas de cada cliente. Faça para a Oscilar as mesmas perguntas de integração e exportação de dados aplicadas aos outros fornecedores e exija os mesmos testes práticos.
Reconhecimento de mercado. A Chartis incluiu a Oscilar no ranking FCC50 de 2026, com premiações nas categorias de Inovação em IA Agente e Customização sem código (Low-Code/No-Code). Trata-se de uma análise técnica de mercado, não de uma classificação interna deste guia, que não define posições para os fornecedores apresentados.
Os nove critérios resumidos
Utilize esta tabela prática para organizar suas reuniões de avaliação e comparar as respostas dos fornecedores de forma direta.
Critério | O que perguntar | Sinal de alerta (resposta fraca) | Como testar com seus dados |
|---|---|---|---|
1. Cobertura do seu próprio risco | Como a lógica do sistema atende aos nossos cenários de risco e divisões de negócio? | Apresentar apenas uma lista de regras prontas em biblioteca | Peça para mostrar quais regras identificariam seus principais cenários em uma amostra de dados |
2. Classificação de risco do cliente atualizada | Quais eventos mudam a classificação e como isso reflete no monitoramento e triagem? | Processamento mensal estático sem explicação clara do cálculo | Simule eventos de risco para clientes da amostra e veja se a nota muda e se propaga no sistema |
3. Seus dados de origem e livre acesso | Com quais sistemas vocês integram de forma nativa e como exportamos os dados? | Oferecer apenas relatórios prontos em vez de exportação completa | Exporte um mês inteiro de dados de teste e cruze com seus registros atuais |
4. Processo unificado do alerta à decisão final de SAR | Mostre o fluxo completo do alerta à decisão final, incluindo casos arquivados | Investigações controladas por planilhas fora do sistema | Simule uma investigação real encerrada do início ao fim na ferramenta |
5. Alteração de regras fácil com histórico | Nossa equipe consegue criar, testar e registrar regras no mesmo dia? | Depender de chamados técnicos ou projetos com o fornecedor para cada ajuste | Faça e simule o impacto de um ajuste de parâmetro real durante os testes |
6. Justificativas explicáveis para auditoria | Mostre os dados e regras que fundamentaram uma decisão de meses atrás | Apresentar notas de decisão sem contexto ou justificativas salvas | Peça para um analista que não participou do caso explicar a decisão usando apenas o registro do sistema |
7. Validação independente por terceiros | Que tipo de documentação e acesso de testes nossos auditores terão? | Alegar segredo de propriedade intelectual sem oferecer documentação técnica | Peça para sua equipe de auditoria analisar o material técnico durante a avaliação |
8. Validação humana no uso de IA | Onde o analista valida cada recomendação gerada pela IA? | IA que toma decisões de encerramento de casos de forma autônoma | Rode análises com IA e garanta que toda ação final dependa de uma aprovação humana registrada |
9. Teste prático com seus dados | Vocês realizam testes retrospectivos e oferecem ambiente em paralelo real? | Apresentar apenas demonstrações prontas com dados do fornecedor | Rode o teste com histórico, depois em paralelo e compare os resultados com sua operação atual |
Compradores de tecnologia já utilizam este modelo de avaliação. Equipes de conformidade de bancos digitais pontuam cada ferramenta analisada com base em critérios objetivos antes de apresentar a recomendação à diretoria. Esta tabela organiza as linhas essenciais para esse tipo de análise comparativa.
Perguntas frequentes
O que deve fazer parte de um software de AML?
Geralmente, um software de AML deve atender a quatro frentes: due diligence e classificação de risco do cliente, monitoramento de transações, triagem de sanções e PEP, além de gestão de casos e preenchimento de SARs. Algumas soluções focam em frentes específicas e outras cobrem todas as quatro de forma integrada. Como cada uma delas gera registros que serão auditados, avalie a qualidade do histórico gerado tanto quanto a capacidade de detecção.
Quais regulamentações e diretrizes devem ser consideradas na escolha do software de AML?
O Manual de Auditoria FFIEC BSA/AML define os padrões de monitoramento, gestão de alertas e decisões de reporte. O Framework do OFAC de 2019 orienta a conformidade de triagem de sanções. As diretrizes para gestão de modelos são definidas pelas normas SR 26-2 e equivalentes do OCC e FDIC (de abril de 2026). A gestão de fornecedores segue as orientações de parcerias com terceiros de 2023, enquanto propostas de atualização de regulamentos seguem em fase de consulta pública pelas autoridades financeiras.
Como realizar testes com dados próprios antes de fechar o contrato?
Rode o software com seu histórico de transações e alertas passados, depois coloque-o para funcionar em paralelo com a sua ferramenta atual usando transações em tempo real. Compare as análises caso a caso com o trabalho da sua equipe. Garanta que o teste em paralelo use os dados reais integrados, e não cargas manuais de arquivos em ambientes limitados. Peça para o sistema evidenciar o que foi detectado e também o que ele deixou passar.
A diretriz SR 11-7 ainda é aplicável para softwares de AML?
Não. A diretriz SR 11-7 foi atualizada em 17 de abril de 2026 pela SR 26-2 (junto ao OCC Bulletin 2026-13 e FDIC FIL-15-2026), que também substituiu o parecer conjunto de 2021 sobre risco de modelos para sistemas de BSA/AML. A validação de modelos contratados de terceiros continua sob responsabilidade das instituições financeiras de acordo com as novas regras. No entanto, lógicas baseadas exclusivamente em parâmetros fixos e regras simples não entram na definição de modelos, assim como ferramentas de IA generativa e assistentes também contam com diretrizes específicas de acompanhamento.
Qual é o melhor software de AML para bancos?
O melhor sistema é aquele que se adequa perfeitamente ao perfil de risco específico do seu banco, mantém a consistência dos dados do cliente em todas as etapas e gera históricos detalhados fáceis de apresentar em auditorias. Nenhuma lista pronta pode determinar isso de antemão. Avalie cada fornecedor com base nos mesmos critérios claros e realize testes práticos com seus próprios dados antes de assinar.
A Oscilar é uma provedora de software de AML?
Sim. A Oscilar disponibiliza uma plataforma integrada para análise de risco em cadastro, crédito, fraude e AML. Conta com ferramentas de monitoramento de transações, gestão de casos, preenchimento de SARs e assistentes inteligentes que apoiam a análise, mantendo a decisão final sempre com o analista humano. A triagem de sanções é integrada a partir de motores especialistas, cujas ocorrências são tratadas dentro da plataforma Oscilar. Avalie a Oscilar sob os mesmos nove critérios aplicados a qualquer outro fornecedor do mercado.

Equipe Oscilar
A equipe da Oscilar é formada por especialistas em diversas áreas de gestão de risco. Estes artigos refletem pontos de vista e conhecimentos de várias fontes e colaboradores de toda a organização.


