Guia do Comprador de Software de PLD para Instituições Financeiras: O Que Saber Antes de Mudar

Última atualização: setembro de 2026

Comprar um software de AML é, na maior parte, um projeto de migração. A demonstração mostra o que um novo sistema pode detectar, mas o risco está em transferir um programa de conformidade ativo para ele sem perder o histórico ou a reputação perante os examinadores. Este guia de compra de software de AML aborda as cinco decisões a serem tomadas antes da assinatura: a comprovação regulatória a ser solicitada, quais dados históricos migram, como os sistemas antigo e novo funcionam lado a lado, quem valida o novo sistema e como os examinadores são mantidos informados. Um provedor que não puder ajudar com os cinco pontos não está pronto para ser contratado.

TL;DR

• A maior parte do risco na compra de um software de AML está na própria transição, e uma escolha errada significa migrar duas vezes.

• Peça as provas que um concorrente já possui: histórico de exames em instituições semelhantes, validações independentes e acesso dos validadores à lógica do sistema e aos seus dados.

• Faça um inventário do histórico que existe apenas no sistema antigo, decida o que migra e o que permanece para retenção de registros, e parta do princípio de que nada migra de forma idêntica.

• Uma execução paralela compara os resultados; a validação comprova os dados e o método. Os critérios de saída acordados previamente decidem quando a execução termina.

• Contrate sua própria validação, verifique ambos os sistemas no período retrospectivo e informe os examinadores antes que o sistema antigo seja desativado.

As cinco decisões que determinam o sucesso ou fracasso da compra de um software de AML

A compra de um software de AML depende de cinco decisões tomadas antes da assinatura do contrato: qual comprovação regulatória o provedor pode oferecer, qual histórico migra, como os sistemas antigo e novo funcionam lado a lado e quando isso termina, quem valida o novo sistema e quando os examinadores ficam sabendo da mudança. Nenhuma delas aparece em uma demonstração, e cada uma deixa um documento que o examinador pode solicitar para ver.

Uma decisão só é concluída quando o documento da última coluna existe.

Uma escolha errada significa uma segunda transição. Um diretor de conformidade de uma empresa de pagamentos disse: "Não quero entrar de cabeça em algo e depois ter que migrar novamente... porque escolhemos a ferramenta errada". Um oficial de controle de qualidade do BSA em um banco comercial chamou a troca de fornecedores de "uma jornada incrivelmente longa".

Este guia aborda a compra após a seleção e a avaliação das opções. A criação da lista de finalistas, por tipo de produto e pelos critérios divulgados pelos provedores, é abordada em um guia separado para comparação de softwares de monitoramento de transações. Testar essa lista com seus próprios dados, avaliando a qualidade dos alertas e o processo em conjunto, é abordado em um guia para avaliação de plataformas de monitoramento de transações de AML.

Por que comprar um software de AML é, na verdade, um projeto de migração

A compra de um software de BSA/AML é um projeto de migração porque a solução atual possui vantagens que um novo sistema precisa conquistar. Os examinadores já a conhecem, e os contratos, o orçamento e a configuração da instituição são construídos em torno dela. Um líder de conformidade de BSA/AML de um banco comunitário descreveu o valor que um sistema estabelecido entrega: "No mundo dos examinadores, ele já foi validado. Portanto... eles podem questionar se você ajustou isso ou aquilo. Mas eles não questionam o sistema, certo? Então, você está pagando por isso, está pagando por tranquilidade".

A transição começa no cronograma do contrato. Um vice-presidente e oficial de risco de AML em um banco comunitário de negócios recusou-se a analisar alternativas porque o contrato com o fornecedor atual tinha acabado de ser renovado, afirmando que ouvir os provedores antes da renovação teria sido o momento ideal. O orçamento também pode não estar com a área de conformidade: um diretor de operações de crimes financeiros de um grande banco regional disse que "a tecnologia é dona do nosso orçamento". Mapeie as datas de renovação e o responsável pelo orçamento antes de iniciar a avaliação.

Um comprador que já passou por uma implementação malsucedida quer provas primeiro. Um tomador de decisão responsável por contratos e exposição regulatória em uma compra disse que sua equipe não queria repetir "a última vez que compramos uma ferramenta e, de certa forma, avançamos na implementação para só depois perceber que havia coisas que simplesmente não podíamos fazer".

Uma migração também precisa de mais aprovações do que uma demonstração sugere. Um oficial de BSA/AML e OFAC de um banco regional listou "nosso grupo de gestão de riscos corporativos, nosso grupo de dados, nossa equipe de TI e segurança da informação... gestão de risco de modelos". Uma fintech tem mais um aprovador, já que, como colocou um líder de risco e conformidade de uma fintech de consumo, "Nosso banco patrocinador exige que aprovemos cada fornecedor que utilizamos". Redija a avaliação de forma que cada um desses grupos possa revisá-la e envolva o banco patrocinador logo no início.

A decisão de desenvolver internamente em vez de comprar é uma escolha à parte, abordada em um guia sobre desenvolver ou comprar agentes de IA em operações de risco reguladas.

A comprovação regulatória a ser solicitada a um provedor

A comprovação regulatória que se deve pedir a um provedor de software de AML são as evidências que um fornecedor estabelecido já possui: histórico de exames em instituições semelhantes à sua, validações por terceiros independentes e a garantia de que seus próprios validadores podem ver e testar como o sistema funciona. Um líder de conformidade de BSA/AML de um banco comunitário mencionou as duas primeiras: "se você conseguir que alguns bancos confirmem que passaram por uma auditoria e... você era o sistema oficial de registro e eles aceitaram bem, ou validações do sistema feitas por terceiros, como auditores independentes".

Pergunte o que seus validadores terão acesso, pois um validador precisa tanto da lógica do sistema quanto dos dados da instituição. Um gerente de BSA em uma cooperativa de crédito descreveu situações em que validadores externos de modelos pediram extrações de dados ao fornecedor atual e ouviram que não era possível fornecê-las: "como é possível que não possamos obter extrações dos nossos próprios dados?" Inclua no contrato o acesso à lógica, acesso de consulta aos dados e extrações completas de dados.

O modelo do fornecedor ainda é de responsabilidade da instituição para validação. A diretriz SR 26-2, a orientação revisada de gestão de risco de modelos emitida pelo Federal Reserve com o Boletim OCC 2026-13 e FDIC FIL-15-2026 em 17 de abril de 2026, afirma que as organizações bancárias "podem não receber do fornecedor o código subjacente, os dados ou a metodologia", mas "os princípios de gestão de risco de modelos continuam aplicáveis". A orientação aponta "a validação de produtos de fornecedores, seja por equipes internas ou externas" como um elemento importante da gestão de risco de modelos.

A due diligence de terceiros é onde o entendimento da instituição sobre o sistema é testado, por isso traga a pessoa que defenderá o sistema na auditoria para a avaliação agora. Um gerente de produto em um banco patrocinador disse a um provedor: "Você não precisa me convencer. Eu entendo, mas não sou eu quem tem que defender isso diante dos examinadores". Como testar as alegações de um provedor sobre sua IA é uma questão à parte, abordada em um guia para avaliar plataformas de risco de AML baseadas em IA.

Que histórico migra para o novo sistema e o que fica para trás

O histórico que vive apenas no antigo sistema de monitoramento, como registros de SAR e CTR, arquivos de alertas e casos e os modelos construídos dentro dele, precisa ser planejado antes da assinatura, pois o que não puder ser migrado manterá o sistema antigo funcionando apenas para fins de retenção de registros. Um analista de BSA e fraudes de um banco comunitário com um programa de banco parceiro descreveu o que precisa ser extraído: "Haverá coisas que extrairemos do [sistema atual] que não estarão no nosso sistema principal, certo? Isso inclui SARs, CTRs, esse tipo de informação".

Quando o histórico não pode ser migrado, o sistema antigo permanece ativo: um líder de controle de qualidade de uma administradora de cartões pré-pagos disse que uma versão local antiga do fornecedor anterior ainda estava funcionando para retenção de registros porque seu histórico não pôde ser migrado para a nova versão, e que o que migrou foi feito manualmente, "o que, se eu puder evitar fazer novamente, gostaria". Os modelos também podem ficar para trás. Um líder de operações de um banco patrocinador disse que o modelo de classificação de risco de clientes do banco funciona dentro do sistema de monitoramento atual e é validado lá.

O trabalho de dados começa antes, no sistema bancário principal, onde um gerente de projetos em um banco de correspondência previa "uma quantidade enorme de mapeamento de dados". A lógica das regras precisa do mesmo inventário, e um oficial de BSA em um banco comunitário com um programa de banco parceiro disse: "[O fornecedor atual] não nos fornece a lógica das regras". Regras que ninguém pode ver não podem ser transferidas ou comparadas.

Antes de assinar, faça um inventário de pelo menos:

• Histórico de SAR e CTR, incluindo o motivo documentado por trás de cada decisão de declarar ou não

• arquivos de alertas e casos, com as respectivas resoluções e as evidências coletadas

• classificações de risco de clientes e os modelos que as produzem, juntamente com sua validação

• configurações de regras e cenários, com a documentação por trás de cada limite

• o histórico de auditoria de quem alterou o quê, e quando

Não presuma que qualquer provedor migrará o histórico de SAR e de casos de forma idêntica. Pergunte o que migra, em que formato, o que permanece legível no sistema antigo e como os dois serão reconciliados para que nenhum alerta ou caso seja perdido.

Como executar os sistemas antigo e novo lado a lado

Uma execução paralela mantém os sistemas de AML antigo e novo funcionando na mesma atividade ao mesmo tempo, para que seus resultados possam ser comparados antes que o antigo seja desligado. Uma execução paralela não é uma validação: ela compara resultados, enquanto a validação comprova os dados que entram no novo sistema e o método que ele aplica. Um diretor de consultoria de risco em uma empresa de consultoria traçou a linha divisória durante uma transição: "A parte da execução paralela não é realmente a validação, é análise e revisão de alertas, é comparação de resultados. Mas a validação são os dados e garantir que... validamos os dados de origem no [novo sistema] e fazemos a qualidade e reconciliação dos dados".

Desative o sistema antigo apenas quando ambas as colunas estiverem concluídas, pois uma não substitui a outra.

Execute um teste paralelo mesmo que o sistema antigo seja simples, pois a instituição precisa ser capaz de provar que isso foi feito. Como disse um diretor de conformidade de um banco comunitário: "Acho que, do ponto de vista do regulador, queremos poder dizer que fizemos [uma execução paralela]".

Como desenhar a execução paralela

1. Defina os critérios de saída antes do início da execução. Registre por escrito quais diferenças devem ser explicadas, o que conta como explicado e quem aprova. A execução termina quando esses critérios forem atendidos.

2. Compare os resultados e espere que a quantidade de alertas seja diferente. Um sistema construído de forma diferente não gerará os mesmos alertas, e um líder de implementação de uma empresa de pagamentos B2B transfronteiriços chamou a comparação do volume de alertas de "comparar bananas com maçãs". De qualquer forma, tentar se equiparar a um sistema antigo com lacunas conhecidas traria pouco valor.

3. Reconcilie o que transita entre os sistemas. Os resultados podem diferir, mas nenhuma transação, alerta ou caso que deveria chegar ao novo sistema pode desaparecer.

4. Poupe os investigadores de retrabalho. Um vice-presidente assistente de estratégia de risco de conformidade de um banco regional queria "um teste paralelo com o que temos hoje e o seu sistema, sem duplicar os alertas". Decida com antecedência quais alertas do sistema os analistas irão tratar.

5. Explique cada diferença por escrito, em ambas as direções: o que o novo sistema detectou que o antigo perdeu e a correção para qualquer falha que ele tenha apresentado.

A declaração conjunta das agências de 2018 sobre inovação, em vigor desde 25 de setembro de 2026, trata testes desse tipo como legítimos. Ela chama os programas-piloto executados paralelamente aos processos existentes de "um meio importante de testar e validar a eficácia de abordagens inovadoras" e afirma que, quando um sistema de monitoramento baseado em IA detecta atividades suspeitas que os processos existentes perderam, "as Agências não presumirão automaticamente que os processos existentes dos bancos são deficientes". A declaração deixa o cronograma a cargo da gestão, que deve avaliar "se, e em que momento, as abordagens inovadoras podem ser consideradas suficientemente desenvolvidas para substituir ou complementar os processos de BSA/AML existentes".

O tempo de sobreposição dos sistemas é, portanto, uma questão de critérios de saída. Um líder de conformidade de BSA/AML de um banco comunitário descreveu a relação custo-benefício: "Quanto mais tempo você executa ambos os sistemas, mais confortável você fica com o novo sistema. Mas, por outro lado, manter... os dois sistemas ativos tem um custo". O comprador e o fornecedor também podem esperar durações diferentes: um vice-presidente e oficial de BSA em um banco de correspondência esperava que os testes paralelos durassem mais do que o fornecedor havia presumido. Critérios acordados antes da assinatura resolvem isso com evidências.

Validando o novo sistema antes de desativar o antigo

Antes de o sistema antigo ser desativado, o novo deve ser validado de forma independente. O manual de exames de BSA/AML do FFIEC afirma que "a metodologia de programação e a eficácia de um sistema de monitoramento devem ser validadas de forma independente para garantir que os modelos estejam detectando atividades potencialmente suspeitas" e que a gestão "deve documentar e ser capaz de explicar os critérios de filtragem, os limites utilizados e como ambos são adequados para os riscos do banco".

A validação na transição ocorre em ambos os sentidos, como descreveu um gerente de conformidade regulatória de uma empresa de auditoria de BSA e validação de modelos: "Tivemos que garantir que o sistema antigo estivesse gerando os alertas corretos para depois rodá-los no novo sistema e certificar que o novo não estava deixando passar nada".

A validação de um fornecedor não substitui a da própria instituição. Um oficial de BSA em um banco comunitário, que contratou uma validação separada após adotar um novo sistema, disse: "obviamente eles oferecem uma validação de modelo, mas nós fizemos uma separada... Foi a melhor coisa que já fizemos... porque aprendemos muito". Uma validação é um exercício prático, não uma declaração formal: sua entrega é um resumo do trabalho efetivamente realizado.

Se um cenário conta como um modelo sob a diretriz SR 26-2 é, por si só, uma decisão a ser documentada. A orientação, que substituiu as diretrizes SR 11-7 e SR 21-8 e continua em vigor a partir de 25 de setembro de 2026, define um modelo como "um método, sistema ou abordagem quantitativa complexa que aplica teorias estatísticas, econômicas ou financeiras para processar dados de entrada em estimativas quantitativas". Ela exclui "processos determinísticos baseados em regras e softwares onde não há teorias estatísticas, econômicas ou financeiras que sustentem seu design ou uso", de modo que a exclusão é condicional: em uma interpretação, uma regra cujo limite foi derivado estatisticamente pode entrar na definição.

Espera-se que a orientação seja mais relevante para organizações bancárias com mais de US$ 30 bilhões em ativos totais, e ela deixa modelos de IA generativa e baseados em agentes fora de seu escopo. Nenhum dos pontos remove a expectativa do manual de exames de que o sistema de monitoramento seja validado de forma independente. O funcionamento detalhado da validação é abordado em um guia sobre validação de modelos de AML após a orientação de abril de 2026.

Mantendo os examinadores ao seu lado durante a mudança

Os examinadores avaliam a mudança de sistema de AML com base nas evidências por escrito da instituição sobre a origem das novas regras e os motivos pelos quais a mudança representa uma melhoria. Um líder de BSA e conformidade de um banco patrocinador, preparando-se para uma auditoria em um sistema recém-adotado, esperava que os examinadores "quisessem saber de onde vêm as regras. ... Em que você se baseou para a calibragem?"

Um oficial de BSA de uma empresa de remessa de valores descreveu a segunda parte como provar "aos nossos examinadores e aos nossos bancos parceiros que é uma mudança para melhor". Um vice-presidente de operações de crédito e conformidade em uma fintech de crédito com bancos parceiros foi mais direto: "Você tem que provar que fez isso, certo? Não basta apenas fazer a coisa certa".

Um vice-presidente sênior e diretor de inteligência financeira de um banco regional descreveu como a familiaridade pode pesar contra a flexibilidade: os examinadores se sentiam confortáveis com o fornecedor atual "porque muitas das instituições que eles examinam o utilizam. ... Mas, ao mesmo tempo, ele não é absolutamente personalizável". O sistema que os examinadores conhecem melhor pode ser justamente aquele que a instituição não consegue ajustar ao seu próprio risco.

O manual do FFIEC orienta os examinadores a "focarem em se o banco possui um processo eficaz de tomada de decisão de SAR, e não em decisões individuais de SAR", e diz que os bancos "devem documentar as decisões de SAR, incluindo o motivo específico para declarar ou não uma SAR". Uma transição deve manter esse registro de decisões ininterrupto entre ambos os sistemas.

Planeje o cronograma de comunicação com o examinador como uma prática padrão. Informe os examinadores antes da transição sobre o plano e o desenho da execução paralela, compartilhe os resultados e a validação independente antes de desativar o sistema antigo e mantenha um registro por escrito de cada reunião de alinhamento. A necessidade de notificação formal depende do regulador, de qualquer acordo de supervisão e, no caso de uma fintech, do contrato com o banco patrocinador; portanto, confirme isso com a assessoria jurídica antes de fechar o plano.

Migração definitiva e como é a linha de chegada

Uma migração definitiva limpa permite que cada alerta e caso em aberto seja concluído no sistema que o gerou e inicia cada novo alerta no sistema novo. A parte difícil é a atividade que abrange a data da migração, porque um cenário que consolida atividades ao longo de um período retrospectivo precisa do histórico anterior à migração para avaliar a atividade posterior a ela. Planeje essas consolidações explicitamente e evite manter os investigadores trabalhando em dois sistemas além do tempo exigido pelos casos em aberto restantes.

A configuração antiga é fruto do trabalho de alguém, por isso trate-a como conhecimento a ser aproveitado. Um oficial de BSA em um banco comunitário disse sobre o sistema que haviam adotado: "Sinto que ele é meu filho. Então, se alguém fala mal dele, sim, eu dediquei muito tempo para acertar as configurações". As pessoas que o calibraram sabem por que cada limite existe, que é exatamente a documentação que um examinador solicitará.

Avalie a equipe de implementação tão bem quanto a equipe de vendas. Um líder de tecnologia de uma empresa de tecnologia de folha de pagamento com um braço bancário disse que, uma vez escolhido o fornecedor, "passamos para a equipe de implementação deles, que às vezes no passado nos deixou na mão". Um vice-presidente de conformidade de uma empresa de pagamentos com cripto, reabrindo a busca após uma transição anterior, chamou "a falta de transparência e comunicação" de gota d'água; portanto, pergunte às referências como o provedor se comportou após a assinatura do contrato.

Após a entrada em operação, continue monitorando o novo sistema em busca de desvios em seus dados, recursos e resultados, e desative o antigo apenas quando as necessidades de retrospectiva e retenção de registros forem atendidas.

Formas comuns de uma migração dar errado

• Tratar a execução paralela como a própria validação

• Avaliar o novo sistema com base em quão próximo o volume de alertas dele é em relação ao antigo

• Presumir que o histórico de SAR, casos e classificações de risco migrará de forma idêntica

• Confiar na validação do fornecedor em vez de contratar uma independente

• Deixar que os examinadores conheçam o novo sistema pela primeira vez apenas na próxima auditoria

• Escolher com base na equipe de vendas e conhecer a equipe de implementação só após a assinatura

• Envolver as áreas de risco de modelos, segurança da informação ou o banco patrocinador apenas no final

É possível modernizar sem substituir tudo de uma vez?

Uma migração não precisa substituir tudo de uma vez, e a primeira escolha é decidir se vai manter, sobrepor ou substituir. Um gerente sênior de entrega de TI para sistemas de crimes financeiros em uma gestora de ativos apresentou os caminhos: "ficar onde estamos e não fazer nada; ficar onde estamos e sobrepor algo por cima; ou buscar outra coisa que substitua nosso sistema de processo e nosso sistema de alertas".

Um caminho em etapas distribui a mudança ao longo do tempo, o que é o seu grande atrativo. Um diretor de conformidade de AML em uma operadora de jogos online queria "dar passos de bebê" em vez de enfrentar "uma migração e treinamento completos de uma só vez". Um sócio de uma consultoria regulatória que assessora bancos ofereceu uma visão de consultor para AML: os reguladores "geralmente não se sentem confortáveis com sistemas de TM totalmente novos", mas podem ser convencidos "ao ter o sistema funcionando em paralelo por cima e, aos poucos, usar o seu sistema para assumir as funções".

A forma como um banco pode fasear essa modernização enquanto mantém seus sistemas anteriores é explicada na página da Oscilar sobre como modernizar o monitoramento sem substituir todos os sistemas de origem. Um caminho em etapas muda apenas uma coisa neste guia: cada etapa que move uma função para o novo sistema precisa de suas próprias evidências, validação e alinhamento com o examinador.

Como a Oscilar aborda uma migração

A abordagem da Oscilar segue as mesmas cinco decisões, e cada pergunta deste guia se aplica tanto à Oscilar quanto a qualquer outro provedor. Antes de fechar o negócio, a Oscilar estrutura a avaliação de pré-produção como uma parceria de design: configuração de dados, um teste retrospectivo contra os alertas históricos da instituição, modo sombra operando paralelamente ao processo existente e um feedback com supervisão humana (human-in-the-loop). Qualquer que seja o provedor que você avaliar, defina os critérios de aceitação para uma prova de conceito antes de começar.

Os agentes podem rodar como uma camada independente por cima da infraestrutura que você já possui ou como parte da plataforma unificada. A Oscilar suporta testes retrospectivos, testes A/B e testes unitários para processos de risco, mantém um histórico de auditoria completo por decisão com justificativas armazenadas e é desenhada para ter supervisão humana. Após a entrada em operação, a Oscilar monitora desvios de dados, de recursos e de conceitos, além de KPIs de resultados por segmento. A instituição continua sendo dona de seus padrões de validação, autoridade de aprovação e responsabilidade regulatória.

Faça à Oscilar as mesmas perguntas de histórico que faria a qualquer outro provedor, começando pelo que migra e em qual formato.

A Chartis Research nomeou a Oscilar para o FCC50 de 2026, com vitórias nas categorias de Inovação em IA de Agentes e Personalização Low-Code/No-Code.

Perguntas frequentes

O que uma instituição financeira deve saber antes de comprar um software de AML?

Uma instituição financeira deve saber que a maior parte do risco ao comprar um software de AML está na migração do sistema antigo para o novo. Antes de assinar, defina a comprovação regulatória que o provedor pode oferecer, quais históricos migram e como são reconciliados, como os sistemas antigo e novo funcionam lado a lado e quando isso termina, quem valida o novo sistema e como os examinadores são mantidos informados.

Por quanto tempo os sistemas de AML antigo e novo devem funcionar em paralelo?

Os sistemas de AML antigo e novo devem funcionar em paralelo até que os critérios de saída acordados antes da execução sejam atendidos, de modo que as evidências determinem a duração em vez de um período fixo. Os critérios definem quais diferenças devem ser explicadas, o que conta como explicado e quem aprova.

O que acontece com alertas históricos, casos e SARs quando você muda de sistema de AML?

Os alertas, casos e SARs históricos migram para o novo sistema ou permanecem legíveis no antigo, que continua ativo para retenção de registros. Alertas e casos em aberto podem ser concluídos no sistema que os gerou, enquanto novos alertas começam no sistema novo. Pergunte a cada provedor o que migra, em que formato e como é reconciliado, e parta do princípio de que nada migra de forma idêntica.

Quando os examinadores devem saber sobre a mudança de sistema de AML?

Os examinadores devem saber sobre a mudança do sistema de AML antes da migração definitiva. Apresente o plano a eles, compartilhe os resultados da execução paralela e da validação independente antes de desativar o sistema antigo e guarde um registro de cada reunião de alinhamento. A necessidade de notificação formal depende do regulador, de qualquer acordo de supervisão e, para uma fintech, do banco patrocinador; portanto, confirme isso logo no início.

O que perguntar às referências de um provedor antes de fazer a migração?

Pergunte às referências de um provedor se eles já passaram por uma auditoria com o sistema ativo e se terceiros independentes já o validaram. Direcione as outras perguntas para o processo de implementação em si, e não para as vendas: quem liderou a migração, como os problemas foram tratados e com que nível de transparência o provedor se comunicou após a assinatura do contrato.

As cinco decisões deste guia são as mesmas independentemente do provedor que você escolher, e os documentos que elas geram são o que os examinadores lerão após a transição. Para a parte de investigação de uma migração, leia sobre a gestão de casos na Oscilar.