Melhores softwares antifraude para ACH: 8 critérios

Última atualização: Outubro de 2026

O melhor software de detecção de fraude ACH para sua instituição é o produto que se adapta à forma como ela realmente envia e recebe pagamentos ACH, e uma lista ranqueada escrita para outra pessoa não pode saber qual produto é esse. Este guia apresenta oito critérios para comparar soluções de detecção de fraude ACH, como se parecem respostas fortes e fracas para cada um, e como testar uma lista final com seus próprios lançamentos antes de assinar. Foi escrito para bancos, cooperativas de crédito, fintechs e remetentes terceirizados.

Resumo (TL;DR)

• Nenhum produto é o melhor software de detecção de fraude ACH para todos. O ideal cobre seus lançamentos e funções, decide antes que os fundos se movimentem, funciona a partir de seus arquivos ACH e dados centrais, permite que sua própria equipe altere e teste regras e registra por que cada lançamento foi interrompido.

• A Oscilar escreveu este guia e vende software de detecção de fraude ACH, por isso o guia não cita nenhum fornecedor e, em vez disso, publica seus critérios.

• O ACH precisa de seus próprios critérios: os lançamentos se movem em arquivos de acordo com um cronograma, cada função vê uma parte diferente do pagamento e o resultado muitas vezes chega tarde como um retorno.

• Peça a cada fornecedor para demonstrar cada critério em seus próprios lançamentos e considere uma resposta vaga como uma resposta fraca.

• Antes de assinar, teste seu próprio histórico com as regras do candidato e, em seguida, execute-as em modo de simulação (shadow) em arquivos reais.

A resposta curta: como escolher um software de detecção de fraude ACH

Para escolher um software de detecção de fraude ACH, comece pelo seu próprio negócio ACH: os lançamentos que você envia e recebe, e as funções que você desempenha. Em seguida, compare os fornecedores com base em oito critérios: cobertura desses lançamentos e funções, quando o software decide em relação aos seus períodos de processamento de arquivos, os dados que ele pode usar, validação de conta e verificações de beneficiários dentro da decisão, quem pode alterar e testar uma regra, por que cada lançamento foi interrompido, uma visão única do cliente em diferentes canais de pagamento e quanto custa para operar o software. Os fornecedores que responderem bem com base em seus próprios lançamentos farão parte da lista final, e um teste retrospectivo e um período de simulação em seu próprio histórico decidirão entre eles.

A Oscilar escreveu este guia e vende software de detecção de fraude ACH, por isso o guia não cita nem ranqueia nenhum fornecedor. Ele publica os critérios que a Oscilar gostaria que qualquer comprador usasse, e uma seção posterior submete a própria Oscilar aos mesmos critérios.

Uma lista de recursos obrigatórios pode não diferenciar os finalistas. Um líder de estratégia de fraude de um grande banco, comparando fornecedores, disse: "Neste ponto, estamos vendo que todos os fornecedores atendem aos requisitos que temos, certo?" O mesmo líder disse que o custo acabaria definindo a decisão, mas que os fatores decisivos seriam a facilidade de uso do sistema e a facilidade com que a equipe pode implementar e testar as mudanças.

Para saber o que é a fraude ACH e as formas que ela assume, comece com nossa visão geral de detecção e prevenção de fraudes ACH.

O que o software de fraude ACH precisa gerenciar que as ferramentas de cartão e transferência bancária não gerenciam

Quer o fornecedor chame de software de detecção, prevenção ou proteção contra fraudes ACH, o produto analisa os lançamentos ACH em busca de sinais de que não foram autorizados ou de que foram induzidos por fraude, e decide, ou ajuda um analista a decidir, quais lançamentos liberar, reter ou investigar antes da liquidação financeira. Três características do ACH moldam o que esse software precisa fazer, e é por isso que as ferramentas criadas para pagamentos com cartão ou transferência bancária não funcionam bem nesse contexto.

Os lançamentos chegam em arquivos, de acordo com um cronograma

Um pagamento com cartão chega individualmente e aguarda uma resposta. Os lançamentos ACH são reunidos em arquivos e trocados de acordo com um cronograma, de modo que o momento de interromper um lançamento suspeito é antes do lançamento do arquivo ou antes da liquidação financeira. Um vice-presidente sênior de pagamentos de um banco descreveu a diferença: os lançamentos ACH ficam em arquivos em vez de chegarem como chamadas de API.

Cada função vê uma parte diferente do pagamento

Uma ODFI (instituição financeira depositária de origem) e seus originadores enviam lançamentos, uma RDFI (instituição financeira depositária de destino) os recebe, e um Remetente Terceirizado fica entre um Originador e sua ODFI. Cada um vê uma parte diferente do mesmo pagamento e enfrenta fraudes diferentes: o lado do envio se preocupa com pagamentos que seus clientes não autorizaram ou foram induzidos a enviar, e o lado do recebimento se preocupa com as contas que os recebem. Muitas instituições atuam tanto como ODFI quanto como RDFI.

Os resultados chegam tarde

Saber se um lançamento foi fraude muitas vezes só fica claro quando ele retorna como uma devolução ou reclamação de cliente, muito após a liquidação. Portanto, o software de detecção de fraude ACH deve ser avaliado com base no que decidiu antes da liquidação e, em seguida, verificado em relação aos retornos que ocorreram posteriormente.

As regras da Nacha sob as quais todas as funções agora operam

Ambas as fases das regras de monitoramento de fraude Nacha de 2026 estão em vigor: a Fase 1 aplica-se desde 20 de março de 2026 a todas as ODFIs e aos maiores Originadores não Consumidores, Provedores de Serviços de Terceiros, Remetentes Terceirizados e RDFIs por volume de ACH de 2023, e a Fase 2 eliminou os limites de volume a partir de 19 de junho de 2026 (na prática, 22 de junho). As partes originadoras devem executar processos e procedimentos baseados em risco, relevantes para sua função, que tenham como "objetivo razoável identificar Lançamentos sob suspeita de não autorizados ou autorizados sob Falsos Pretextos", as RDFIs devem fazer o mesmo para os créditos que recebem, e cada parte coberta analisa seus processos pelo menos uma vez por ano. As regras não prescrevem nenhum método e nenhum produto, de modo que o software pode executar e comprovar um programa de monitoramento de fraude ACH, mas não pode, por si só, tornar uma instituição em conformidade. O que cada função deve ter estruturado sob essas regras está detalhado em nosso guia de preparação para as regras de fraude Nacha de 2026.

Os oito critérios e como usá-los

Classifique cada fornecedor em cada critério como forte, parcial ou fraco, e peça uma demonstração com seus próprios lançamentos em vez de uma apresentação de slides. Considere uma resposta vaga como uma resposta fraca. Os oito critérios são:

1. Os lançamentos e funções que ele cobre

2. Quando ele decide, medido em relação aos seus períodos de processamento de arquivos

3. Os dados que ele pode usar: sistema central (core), canais digitais (online banking) e os arquivos ACH

4. Validação de conta e verificações de beneficiários dentro da mesma decisão

5. Quem pode alterar uma regra e como uma alteração é testada

6. Por que um lançamento foi interrompido, em termos que um auditor possa compreender

7. Uma visão única do cliente em ACH e outros canais de pagamento

8. Quanto custa para operar: volume de alertas e pagamentos legítimos interrompidos

O líder de estratégia de fraude de um grande banco citado acima resumiu a avaliação em três perguntas: "quão fácil é para nós usar? Porque não queremos depender do fornecedor para fazer alterações. Quão fácil é testar quando queremos implementar mudanças sem afetar a produção? Até onde podemos ir nos dados legados?" Os critérios 3 e 5, e a prova de conceito descrita mais adiante, transformam essas perguntas em testes práticos.

Os critérios avaliam o que o software faz com seus lançamentos. As verificações de detecção internas, como validação de conta, correspondência de nome, regras de frequência e valor, verificações de alterações de beneficiários, sinais de dispositivo e sessão e análises de taxa de retorno, são um assunto à parte. Como funciona cada uma dessas verificações, e o que cada uma delas deixa passar, é abordado método por método em nosso guia de métodos de detecção de fraude ACH.

1. Os lançamentos e funções que ele cobre

Cobertura significa quais dos seus fluxos ACH o software pode ver e agir: débitos e créditos de saída para uma ODFI e seus Originadores, créditos de entrada para uma RDFI e o fluxo misto de um remetente terceirizado em vários Originadores. Uma instituição que é tanto ODFI quanto RDFI precisa de cobertura em ambos os lados, pois as regras da Nacha descritas acima se aplicam a cada função que ela desempenha.

Como se parece uma resposta forte. O fornecedor distingue o recebimento da originação e demonstra cada fluxo que você realiza em seus próprios lançamentos. Um diretor de produtos de gestão de tesouraria de um banco apontou essa distinção como o que realmente importava: "Acho que o que estou ouvindo e que é importante para mim é que vocês diferenciam o recebimento da originação". Um Originador de débitos WEB também precisa de validação de conta no primeiro uso de um número de conta e em cada alteração, o que o critério 4 cobre.

Como se parece uma resposta fraca. Uma cobertura de ACH que se limita apenas a débitos de saída, deixando os créditos de entrada para outro sistema ou para ninguém.

2. Quando ele decide, medido em relação aos seus períodos de processamento de arquivos

O tempo de resposta refere-se ao momento do seu ciclo ACH em que o software toma a decisão: quando o pagamento é iniciado, quando o arquivo é gerado, antes do arquivo ser liberado ou após a liquidação. Os períodos de liquidação são o prazo limite e, a partir de 17 de setembro de 2027, o Same Day ACH processará pagamentos de até US$ 10 milhões cada (acima do limite anterior de US$ 1 milhão), o que deixará menos tempo para agir em pagamentos maiores.

Como se parece uma resposta forte. O software avalia cada lançamento quando ele é iniciado ou, no máximo, antes do arquivo ser liberado, podendo reter ou cancelar um lançamento antes da liquidação. O vice-presidente sênior de pagamentos de um banco, que descreveu o ACH como algo que vive em arquivos, queria que os lançamentos fossem verificados no momento da iniciação do ACH, e não após a criação do arquivo. Um vice-presidente executivo e diretor de fraudes de um banco disse que a preferência é sempre interceptar a movimentação de dinheiro antes que ele saia e conter a invasão de contas antes que cause danos significativos.

Para entender o que o tempo real deve significar na prática e como testar a alegação de um fornecedor, consulte o que uma plataforma de prevenção de fraudes em tempo real deve fazer.

Como se parece uma resposta fraca. Uma alegação de avaliação em tempo real que, na verdade, significa analisar o arquivo somente depois de gerado, ou um relatório na manhã seguinte sobre lançamentos que já foram liquidados.

3. Os dados que ele pode usar: sistema central, canais digitais e os arquivos ACH

Dados significam quais dos seus sistemas o software lê e como as informações chegam até ele. Os lançamentos ACH começam nos canais digitais ou em um Originador, passam pelo sistema central (core) e pelo processador ACH, e terminam em arquivos. Portanto, uma ferramenta que enxerga apenas um desses pontos vê apenas parte do risco.

Como se parece uma resposta forte. O software funciona a partir dos próprios arquivos ACH, sem necessidade de carregamento manual, e a partir dos canais digitais e sistemas centrais onde os lançamentos são criados. O vice-presidente sênior de pagamentos de um banco citado no critério 2 queria excluir o trabalho manual e carregar os arquivos ACH diretamente, mesmo com um grande volume de arquivos. O diretor de produtos de gestão de tesouraria de um banco citado no critério 1 disse que cobrir todas as formas de início de um pagamento significa integrar com o internet banking ou olhar além dos canais para os sistemas de produção, como o processador ACH e o sistema de transferências.

Pergunte com o que o fornecedor realmente já se integrou. O sistema central de uma instituição pode não ser unificado. O vice-presidente executivo e diretor de fraudes de um banco citado no critério 2 mencionou que bancos que cresceram por aquisição podem operar vários sistemas legados e centros de dados, em vez de uma única plataforma central. Um gerente de conformidade de BSA/AML em uma cooperativa de crédito disse que seus canais digitais altamente personalizados dificultam a conexão de chamadas de API que fornecem dados úteis em tempo real.

Os termos para compartilhamento de dados também são importantes. Um diretor de risco em uma fintech de investimentos disse que os dados históricos para treinamento de modelos poderiam ser compartilhados sob um acordo de confidencialidade, mas que o compartilhamento contínuo de dados seria muito difícil. Defina esses termos antes do início da prova de conceito.

Como se parece uma resposta fraca. Uma ferramenta que precisa de um evento de API que seu sistema central não consegue enviar, ou de um carregamento manual de arquivos feito todas as noites.

4. Validação de conta e verificações de beneficiários dentro da mesma decisão

A validação de conta, a correspondência de nomes e as verificações de alteração de beneficiários informam ao software se a conta que ele está prestes a debitar ou creditar é realmente a conta correta. Este critério refere-se ao destino desses resultados.

Como se parece uma resposta forte. O resultado de uma validação de conta, de uma correspondência de nome ou de uma alteração nos dados do beneficiário serve como entrada para a mesma decisão sobre o lançamento, juntamente com tudo o que o software já sabe, em vez de ser exibido em uma tela separada para alguém verificar mais tarde. A regra de débito WEB da Nacha estabelece um patamar mínimo: desde 19 de março de 2021, um Originador de débitos WEB deve validar a conta no primeiro uso do número da conta e sempre que houver alteração. O requisito mínimo é garantir que a conta esteja ativa e possa aceitar lançamentos ACH, independentemente de quem seja o titular. O software deve permitir que você adicione verificações de titularidade e de nome conforme o seu nível de risco exigir.

As alterações de beneficiários são ainda mais críticas para casos de Falsos Pretextos. Desde 1º de outubro de 2024, a definição de Falsos Pretextos da Nacha cobre pagamentos induzidos por alguém que falsifica sua identidade, sua autoridade para agir em nome de outra pessoa ou a titularidade da conta a ser creditada — incluindo comprometimento de e-mail comercial (BEC) e personificação de fornecedores, folhas de pagamento e outros beneficiários. Esses golpes geralmente envolvem uma conta de destino nova ou alterada. Portanto, a alteração em si, como novos dados bancários de um fornecedor ou uma nova conta de depósito direto de um funcionário, deve ser um evento que o software consiga visualizar e agir antes que o próximo pagamento seja enviado.

Como se parece uma resposta fraca. Validação vendida como um produto separado, cujo resultado nunca chega à decisão de fraude.

5. Quem pode alterar uma regra e como uma alteração é testada

A gestão das regras refere-se a quem cria e altera as regras de detecção, e se uma alteração pode ser testada antes de ir para o ambiente de produção.

Como se parece uma resposta forte. Sua própria equipe de fraude escreve e altera as regras, testa retrospectivamente cada alteração em seu próprio histórico e a executa em modo de simulação antes que ela bloqueie qualquer transação. Um gerente de análise e programas de AML em uma fintech lembrou que, em um emprego anterior, dependia do fornecedor para criar uma regra e precisava cobrá-lo constantemente por isso. Um analista de fraude na mesma fintech desejava testes retrospectivos tanto para as regras que geram alertas e casos para análise quanto para as regras que bloqueiam transações diretamente. O diretor de produtos de gestão de tesouraria de um banco citado no critério 1 defendeu a importância dos testes: até que uma nova regra seja testada, não há como saber se ela vai sobrecarregar a equipe com exceções ou se não mudará absolutamente nada.

Como se parece uma resposta fraca. Alterações que precisam ser solicitadas por meio de um chamado para o fornecedor, ou um conjunto de regras que sua equipe não consegue visualizar.

O vice-presidente executivo e diretor de fraudes de um banco citado no critério 2 descreveu seu sistema como uma caixa preta: "não temos acesso a ele, nem temos a capacidade de alterar o conjunto de regras. Recebemos sistemas meio que padronizados. Pode haver uma configuração que consigamos ajustar, mas é só isso". O líder de estratégia de fraude de um grande banco citado anteriormente descreveu outro cenário, no qual a lógica é escrita manualmente como código, sem um motor de decisão, e entregue a outra equipe de TI para implementação e agendamento.

6. Por que um lançamento foi interrompido, em termos que um auditor possa compreender

Explicabilidade significa se uma pessoa consegue compreender por que o software interrompeu, reteve ou liberou um lançamento, e o que mudou nas regras desde então. Auditores, inspetores e equipes de risco de modelo farão essa pergunta.

Como se parece uma resposta forte. Cada decisão mostra as regras e sinais que foram acionados e os dados analisados, e cada alteração de regra é registrada com informações de quem a fez e quando. O vice-presidente executivo e diretor de fraudes de um banco citado no critério 5 queria poder rastrear uma alteração inesperada e descobrir quem a fez e quando. Ele mencionou que o grupo de gestão de risco de modelo do banco valoriza a compreensão dos modelos de IA fundamentais. Como a Nacha espera que cada parte coberta revise seus processos de monitoramento de fraude pelo menos uma vez por ano, o software também deve gerar os registros de que essa revisão precisa: quais regras foram acionadas, o que mudou e o que aconteceu com os lançamentos que foram interrompidos.

Como se parece uma resposta fraca. Uma pontuação de risco (score) sem justificativas associadas e sem histórico de quem alterou qual regra.

7. Uma visão única do cliente em ACH e outros canais de pagamento

O contexto multicanal refere-se à capacidade da decisão de ACH de visualizar o que o mesmo cliente está fazendo em cartões, transferências bancárias e outros pagamentos. O mesmo fraudador pode atuar em mais de um canal, e uma ferramenta de ACH isolada adiciona apenas mais um sistema para gerenciar.

Como se parece uma resposta forte. A plataforma de detecção de fraude ACH utiliza as outras atividades do cliente, de modo que um mesmo fraudador apareça como um único caso, em vez de alertas não relacionados em filas separadas. Os compradores também evitam adicionar mais silos de dados: o vice-presidente sênior de pagamentos de um banco citado no critério 2 disse que, com tantos fornecedores e softwares já instalados, seriam contra a adição de mais um. Para saber como avaliar uma pontuação unificada entre cartão, ACH e transferências, consulte como avaliar a pontuação de fraude em cartão, ACH e transferências bancárias.

Como se parece uma resposta fraca. Uma ferramenta exclusiva para ACH com sua própria fila de casos, incapaz de visualizar as outras atividades do cliente.

8. Quanto custa para operar: volume de alertas e pagamentos legítimos interrompidos

O custo de operação refere-se ao trabalho de análise gerado pelo software e aos pagamentos legítimos que ele bloqueia, além do seu preço de aquisição. Uma ferramenta que detecta fraudes interrompendo lançamentos legítimos repassa o custo para os seus clientes e para a sua equipe de operações.

Como se parece uma resposta forte. O fornecedor demonstra, com base nos seus próprios dados, quantos lançamentos legítimos suas regras interromperiam e quantos alertas gerariam, e não apenas as fraudes que detectariam. Além disso, sua equipe deve ser capaz de ajustar os falsos positivos sem precisar de um projeto de consultoria do fornecedor. Um vice-presidente sênior e diretor de operações de depósitos e agências de um banco destacou essa limitação: queriam "algo que não gerasse muito trabalho extra, pois nossa equipe é limitada".

Como se parece uma resposta fraca. Uma taxa de detecção que não traz informações sobre os lançamentos legítimos que as regras bloqueiam ou sobre os alertas adicionais que criam.

Como realizar uma prova de conceito de ACH com seus próprios dados

Uma prova de conceito para software de detecção de fraude ACH deve mostrar o que as regras do candidato teriam feito com seus lançamentos históricos e, em seguida, o que fazem com arquivos reais em tempo real, antes que qualquer bloqueio aconteça. Isso pode ser feito em cinco etapas.

1. Classifique seu histórico. Reúna lançamentos históricos com seus resultados conhecidos: fraudes confirmadas, retornos não autorizados e os lançamentos que você sabe que foram legítimos.

2. Simule com as regras do candidato. Compare os alertas e bloqueios que as regras teriam gerado com o que realmente aconteceu. O líder de estratégia de fraude de um grande banco citado anteriormente descreveu a mesma análise retrospectiva em sua instituição: para uma determinada lógica, demonstre os volumes, a experiência esperada do cliente e a mitigação de perdas antes que a lógica vá para a produção.

3. Execute em modo de simulação (shadow) em arquivos reais. Deixe as regras avaliarem os lançamentos reais sem bloqueá-los e compare suas decisões com o seu processo atual.

4. Verifique o que o teste retrospectivo não pôde capturar. Um líder de estratégia de fraude de uma fintech de consumo reconheceu que um conjunto de dados históricos nem sempre trará sinais de dispositivo e comportamento; portanto, avalie esses sinais durante o período de simulação.

5. Defina os termos de dados primeiro. Como observado no critério 3, os dados históricos sob um acordo de confidencialidade podem ser mais fáceis de compartilhar do que um fluxo em tempo real. Portanto, estabeleça esse acordo antes do início do teste.

Nem todas as instituições financiarão um projeto-piloto. Um gerente de programa que conduz um processo de seleção (RFP) de plataforma de fraude e AML em um banco disse que vale a pena ter um piloto para um fornecedor tão essencial para as operações diárias, mas, após sugerir isso várias vezes, percebeu que não havia interesse interno. Onde for esse o caso, exija ao menos o teste retrospectivo, pois ele roda em dados históricos e nunca toca nos sistemas de produção. Para a abordagem geral de testes de software de fraude antes de comprar, consulte como testar softwares de detecção de fraude antes de comprar.

Quem aprova a contratação e o que vão perguntar

A compra de um software de detecção de fraude ACH em um banco ou cooperativa de crédito geralmente envolve várias avaliações, cada uma com suas próprias perguntas.

• Se devemos fazer e como. O vice-presidente executivo e diretor de fraudes de um banco citado no critério 2 descreveu pelo menos duas etapas de avaliação: uma decisão em nível executivo sobre a viabilidade do projeto e, em seguida, uma análise técnica de como executá-lo, feita por arquitetos e gerentes de risco.

• Gestão de fornecedores e segurança tecnológica. O diretor de produtos de gestão de tesouraria de um banco citado no critério 1 descreveu um grupo de gestão de fornecedores que revisa seguros, contratos e termos, além de um grupo de segurança tecnológica que analisa testes de invasão (pentests) e relatórios SOC.

• Aprovação operacional. O gerente de programa que conduz a seleção de plataforma de fraude e AML em um banco previu que o Diretor de Riscos (CRO) precisaria assinar, pois o banco precisaria de uma validação operacional.

Um histórico de integração fraco pode desqualificar um fornecedor por si só. O mesmo vice-presidente executivo e diretor de fraudes de um banco mencionou um fornecedor que "tinha soluções muito interessantes, mas nunca havia feito uma integração com um grande sistema central de core banking antes". Pergunte a cada fornecedor com quais sistemas centrais e processadores semelhantes aos seus ele já se integrou e converse com essas instituições.

Onde a Oscilar se enquadra, avaliada sob os mesmos critérios

A Oscilar escreveu este guia e vende software de detecção de fraude ACH, por isso deve ser submetida aos mesmos oito critérios de qualquer outro fornecedor. A Oscilar é uma Parceira Preferencial da Nacha para Validação de Conta, Monitoramento de Fraude e Prevenção de Risco e Fraude.

A Oscilar é uma plataforma unificada: estrutura de dados em tempo real, inteligência de dispositivo e comportamento, regras e gestão de casos em uma única solução, com agentes nativos do sistema. Os agentes podem rodar como uma camada independente sobre a infraestrutura que você já possui ou como parte da plataforma unificada. A especificação técnica da plataforma da Oscilar é de decisões em menos de 100 milissegundos. Como essa é uma especificação técnica e não um benchmark independente, meça esse tempo com seus próprios lançamentos durante o período de simulação.

Sobre o critério 5, conforme publicado em oscilar.com: "A SoFi reduziu seu tempo de lançamento no mercado para novas políticas de risco em 50% usando a interface de políticas de risco sem código da Oscilar". Teste essa afirmação da mesma forma que testaria qualquer alegação de fornecedor, pedindo à Oscilar para alterar e testar retrospectivamente uma regra em seu próprio histórico.

Avalie a Oscilar no restante da lista da mesma forma: pergunte quais de seus lançamentos e funções ela cobre, em que ponto do seu ciclo de arquivos ela decide, quais de seus sistemas ela lê e de que forma, e como suas regras se comportam em um teste retrospectivo e em um período de simulação em seus próprios lançamentos. Para ver como a Oscilar aborda a fraude de pagamento, consulte a proteção contra fraude de transações da Oscilar.

Os oito critérios em resumo

Preencha as respostas de cada fornecedor ao lado dessas linhas, com base em demonstrações feitas em seus próprios lançamentos, antes da reunião de definição da lista final.

Perguntas frequentes

Quais são as melhores soluções de detecção de fraude ACH?

As melhores soluções de detecção de fraude ACH são aquelas que cobrem os lançamentos e funções de uma instituição, decidem antes que os fundos se movimentem, funcionam a partir de seus arquivos ACH e dados do sistema central, permitem que sua própria equipe altere e teste regras e registram o motivo pelo qual cada lançamento foi interrompido. O produto que faz isso melhor varia de banco para banco, de cooperativa de crédito ou de fintech. Portanto, compare os fornecedores com base nesses critérios e teste os finalistas em seu próprio histórico antes de assinar o contrato.

Quais plataformas detectam fraudes de pagamento ACH antes da movimentação dos fundos?

Plataformas que avaliam cada lançamento quando ele é iniciado ou, no máximo, antes que seu arquivo seja liberado, podem detectar fraudes de pagamento ACH antes da movimentação dos fundos, desde que também consigam reter ou cancelar um lançamento sinalizado antes da liquidação financeira. Peça a cada fornecedor para demonstrar em que ponto do ciclo de arquivos a decisão ocorre e o que o sistema pode fazer com um lançamento sinalizado. Um relatório sobre lançamentos que já foram liquidados apenas encontra a fraude depois que o dinheiro já saiu.

Qual software ajuda os originadores a monitorar pagamentos ACH contra fraudes de falsos pretextos?

Os originadores obtêm o melhor suporte de softwares que tratam a alteração de dados do beneficiário (como novos dados bancários de um fornecedor ou uma nova conta de folha de pagamento) como um evento acionável e que integram os resultados de validação de conta e correspondência de nomes na mesma decisão de liberação do lançamento. A definição de Falsos Pretextos da Nacha, em vigor desde 1º de outubro de 2024, cobre fraudes de comprometimento de e-mail comercial (BEC) e personificação de fornecedores, folhas de pagamento e outros beneficiários, táticas que geralmente dependem de uma alteração de conta de destino. O funcionamento das verificações de alteração de beneficiário e destino é detalhado em nosso guia de métodos de detecção de fraude ACH.

O software de detecção de fraude ACH garante a conformidade de uma instituição com as regras da Nacha?

Não. As regras de monitoramento de fraude da Nacha exigem que cada parte coberta execute processos e procedimentos baseados em risco e adequados à sua função, revisando-os pelo menos uma vez por ano, sem prescrever um método ou produto específico. O software pode executar esses processos e manter os registros comprobatórios de sua execução, mas o programa de conformidade e sua revisão anual continuam sendo responsabilidade da instituição.

O que deve desqualificar um fornecedor de detecção de fraude ACH?

Um conjunto de regras que sua própria equipe não consegue ver ou alterar, a impossibilidade de testar uma alteração em seu histórico antes que ela vá para produção e a falta de histórico de integração com uma plataforma de core banking semelhante à sua são fatores que devem desqualificar um fornecedor. A recusa em realizar um teste retrospectivo com seus próprios lançamentos ou a incapacidade de mostrar em que momento do processamento de arquivos o software decide também são motivos para desqualificação.

Por que esta lista não cita nenhum fornecedor?

Esta lista não cita fornecedores porque a Oscilar, que a escreveu, vende software de detecção de fraude ACH, e um ranking publicado por um vendedor não seria uma classificação neutra. Em vez disso, publicar os critérios permite que o comprador aplique os mesmos testes a todos os fornecedores, incluindo a Oscilar, construindo a lista final a partir das respostas práticas que cada fornecedor apresentar com base nos lançamentos reais do próprio comprador.