Melhor Software de Monitoramento de Transações: 9 Critérios a Considerar

Última atualização: setembro de 2026

O melhor software de monitoramento de transações para um banco ou fintech é o produto que realiza as tarefas de monitoramento que a instituição precisa, em seus próprios dados, com decisões que seus auditores possam reconstruir. Uma lista classificada não pode saber isso com antecedência, por isso este guia oferece nove critérios claros para criar, em vez disso, uma lista de finalistas para prevenção a fraudes e PLD. A Oscilar escreveu este guia e vende software de monitoramento de transações. Por esse motivo, não nomeia nem classifica produtos, e avalia a própria Oscilar de acordo com os mesmos critérios no final.

TL;DR (Resumo)

• Uma lista dos melhores softwares de monitoramento de transações é tão útil quanto seus critérios definidos e seu autor. Esta lista foi escrita pela Oscilar, que vende soluções nessa categoria, e não nomeia produtos.

• Decida primeiro quais tarefas você deseja atender: decisões de fraude em tempo real no fluxo de pagamento, monitoramento de PLD ao longo do tempo ou ambos em uma única plataforma com responsabilidades mantidas separadas.

• Pondere os nove critérios com as equipes de fraude, conformidade e tecnologia antes de qualquer demonstração e, em seguida, faça as mesmas perguntas a todos os fornecedores.

• Considere uma resposta vaga como uma resposta fraca e teste os fornecedores selecionados com seus próprios dados antes de assinar o contrato.

A resposta rápida: como escolher um software de monitoramento de transações

Para escolher um software de monitoramento de transações, decida primeiro quais tarefas de monitoramento você quer atender: decisões de fraude em tempo real no fluxo de pagamento, monitoramento de PLD do comportamento do cliente ao longo do tempo ou ambos em uma única plataforma, mantendo as decisões de cada equipe separadas. Em seguida, estabeleça critérios ponderados entre as equipes de fraude, conformidade e tecnologia, faça as mesmas perguntas a todos os fornecedores e pontue as respostas — considerando respostas vagas como fracas. Os fornecedores que passarem por esse crivo formarão uma lista seleta de boas opções para testar com seus próprios dados antes de assinar.

A Oscilar escreveu esta lista e vende software de monitoramento de transações para fraude e PLD, por isso a lista não nomeia nem classifica produtos. Os nove critérios se aplicam a todos os fornecedores, e uma seção posterior avalia a própria Oscilar com base neles, usando apenas informações que podemos comprovar.

Como ler uma lista de 'melhor software de monitoramento de transações'

Uma lista dos melhores softwares de monitoramento de transações só vale a pena ser lida se responder a três perguntas sobre si mesma: quem a escreveu, quais critérios foram usados e se o autor vende algum dos produtos classificados. Uma lista que não responde a nenhuma dessas perguntas geralmente reflete apenas os nomes que o autor conhece, e muitas listas de finalistas reais são criadas dessa mesma forma.

Um sócio de uma consultoria regulatória que assessora bancos descreveu a atração por um nome familiar: "Sabemos que os bancos não gostam de correr riscos... Então, eles vão preferir algo que tenha um nome forte, um nome tradicional." Um administrador sênior de sistemas de fraude em uma cooperativa de crédito disse que sua equipe monta a lista com base nos fornecedores com quem os tomadores de decisão já conversaram, nos que instituições parceiras usam e nos nomes de que já ouviram falar, para depois ir filtrando. Um vice-presidente sênior e diretor de gestão de risco de fraude em um banco comercial disse que suas primeiras perguntas vão para os fornecedores que já estão na casa e, só depois, para "o que mais existe no mercado que possa ser interessante para nos ajudar a gerenciar o risco".

Uma lista de finalistas disciplinada define primeiro os critérios e seus pesos e, em segundo lugar, olha para os nomes. O resultado deve ser um pequeno conjunto de opções viáveis. Um diretor de PLD de uma gestora de recursos descreveu a tarefa: "No final das contas, preciso apresentar ao meu chefe algumas boas opções, sabendo que algumas delas provavelmente não vão dar certo."

As duas tarefas de monitoramento e os tipos de software desenvolvidos para elas

O software de monitoramento de transações realiza duas tarefas diferentes, e a maioria dos produtos é desenvolvida em torno de uma delas. A tomada de decisão de fraude em tempo real avalia um pagamento ou evento enquanto ele está em andamento e o bloqueia, retém ou autoriza antes que o dinheiro seja movimentado. Já o monitoramento de PLD analisa o comportamento do cliente ao longo do tempo, gera alertas para investigação e apoia os relatórios de atividades suspeitas (SARs) que uma instituição envia após o ocorrido.

O tempo é o que separa essas duas tarefas de forma mais clara. Um líder de conformidade de BSA/PLD em um banco comunitário explicou que, em PLD, "os alertas são gerados mensalmente, e há uma razão para isso", enquanto "do lado do combate à fraude... você quer detectar na hora, quando ainda há tempo de estornar, de agir e minimizar as perdas".

Os auditores têm um vocabulário próprio para explicar como funciona o monitoramento interno de cada tipo de produto. Esse vocabulário vem do manual de auditoria de BSA/PLD do Federal Financial Institutions Examination Council (FFIEC). O manual divide o monitoramento automatizado em dois tipos de sistema, e qualquer um deles pode fazer parte dos produtos descritos abaixo.

Nas palavras do manual, "Os sistemas de monitoramento incluem sistemas baseados em regras e sistemas inteligentes" e "Os sistemas inteligentes são adaptáveis e podem filtrar transações com base no histórico de atividades da conta ou comparar a atividade do cliente com um grupo de pares pré-estabelecido ou outros dados relevantes".

Os compradores hoje costumam estruturar a compra como uma escolha entre um sistema de monitoramento de transações de PLD, uma solução de monitoramento de fraude ou uma plataforma única que faça ambos. Uma empresa de serviços financeiros para o consumidor estruturou sua avaliação exatamente dessa forma e depois analisou até que ponto queria combinar as revisões que cada lado processa. Os tipos de software no mercado alinham-se com essas escolhas.

A tabela organiza os produtos pela tarefa de monitoramento para a qual foram desenvolvidos, que é a primeira definição que uma lista de finalistas deve resolver.

Uma camada de sobreposição pode ser facilmente confundida com um sistema de monitoramento completo. Um diretor de PLD de uma gestora de recursos disse: "Alguns fornecedores... oferecem apenas sobreposições, sabe? Não são motores de regras. Não são realmente ferramentas de gestão de casos." O desejo inicial dele era uma solução de ponta a ponta com motor de regras, gestão de casos e triagem que funcionasse de forma nativa com IA. Para a compra exclusiva de detecção de fraude, incluindo as formas como esse mercado opera, consulte o guia do comprador de software de detecção de fraude.

Uma plataforma ou duas para fraude e PLD?

O monitoramento de fraude e PLD pode compartilhar a mesma plataforma quando ambas as equipes se beneficiam dos mesmos dados e da mesma visão do cliente, desde que cada equipe ainda tenha autonomia sobre suas decisões. Os compradores discordam sobre até onde ir. Um diretor sênior de crédito de um banco digital disse: "Eu vejo o monitoramento de transações de fraude e PLD como um pacote único." Já uma oficial de PLD de uma fintech de pagamentos pré-pagos viu o risco disso quando a equipe de PLD não tinha orçamento próprio para plataformas: "acabamos presos usando o que a equipe de fraude usava, e adivinhe o que a fraude faz? Eles escolhem uma plataforma que é boa para fraude e ruim para PLD, o que gera uma série de problemas."

Uma compra compartilhada também envolve a decisão de duas equipes. Um líder de conformidade de BSA/PLD em um banco comunitário disse que precisaria do aval da equipe de fraude antes de substituir um sistema do qual a fraude dependia para seus alertas. As ferramentas também se dividem de acordo com o que precisa acontecer em tempo real: um administrador sênior de sistemas de fraude em uma cooperativa de crédito disse que o monitoramento de fraude lá roda em fornecedores separados porque o sistema de monitoramento de PLD não opera em tempo real.

No setor bancário, uma estrutura totalmente integrada é rara. Um vice-presidente sênior e diretor de PLD e sanções de um grande banco regional disse: "Totalmente integrado é sempre melhor, mas é um mercado muito fragmentado. No setor bancário, raramente se consegue isso." Isso deixa os caminhos definidos por um gerente sênior de TI para sistemas de crimes financeiros em uma gestora de recursos: "ficar onde estamos e não fazer nada; ficar onde estamos e colocar uma sobreposição por cima; ou adotar algo novo que substitua nosso sistema de processo e sistema de alertas."

Para PLD, um sócio de uma consultoria regulatória que assessora bancos sugeriu primeiro uma sobreposição, porque os reguladores "geralmente não se sentem confortáveis com sistemas de monitoramento totalmente novos", e o novo sistema pode assumir as funções gradualmente. O argumento completo para compartilhar os sinais mantendo a responsabilidade separada está no guia sobre como unificar fraude e PLD sem misturar responsabilidades.

Implantação: onde o software fica e ao que ele precisa se conectar

O software de monitoramento de transações é implantado no fluxo de pagamento, fora dele, ou em ambos, seja como uma camada independente sobre os sistemas existentes ou como uma plataforma completa. O software no fluxo de pagamento precisa retornar uma decisão antes que o pagamento seja concluído, enquanto o software fora do fluxo analisa a atividade após o ocorrido e pode rodar em lotes (batch).

A integração deve fazer parte da lista de critérios desde o início. Um vice-presidente sênior e diretor de gestão de risco de fraude em um banco comercial disse que, exceto nos bancos muito pequenos, a prevenção a fraudes roda com vários fornecedores, então a pergunta para qualquer candidato é se sua arquitetura pode funcionar em paralelo com as outras. Um líder de tecnologia de crimes financeiros de um grande banco disse: "Nem sequer colocamos na lista de finalistas muitos dos grandes fornecedores tradicionais porque percebemos que eles estavam tentando improvisar IA e modernizar de forma superficial sua plataforma legada."

Para ACH, o monitoramento de fraude é agora uma obrigação. As regras de monitoramento de fraude da Nacha, que entraram em vigor em duas fases em 2026, exigem que os participantes "estabeleçam e implementem processos e procedimentos baseados em risco razoavelmente planejados para identificar transações ACH iniciadas devido a fraude". A Fase 1 entrou em vigor em 20 de março de 2026 para todas as instituições de origem (ODFIs) e para os demais participantes de grande porte. A Fase 2 entrou em vigor em 19 de junho de 2026 e eliminou os limites de tamanho, de modo que cada instituição receptora (RDFI) deve agora realizar o monitoramento baseado em risco dos créditos ACH que recebe.

Os nove critérios e como usá-los

Os nove critérios abaixo são fundamentais para selecionar sistemas de monitoramento de transações em fraude e PLD. Cada um vem com a pergunta a ser feita ao fornecedor e a descrição de uma resposta fraca. Eles estão acima do nível de funcionalidades específicas: um checklist de funcionalidades para monitoramento de transações em tempo real cobre o que o sistema em tempo real em si precisa fazer.

Use os critérios em três etapas:

1. Pondere os critérios antes de avaliar qualquer fornecedor, com o alinhamento das equipes de fraude, conformidade e tecnologia sobre os pesos.

2. Faça as mesmas perguntas por escrito a todos os fornecedores e guarde as respostas.

3. Pontue cada fornecedor com base na resposta enviada, considerando respostas vagas como fracas.

Um líder de estratégia de fraude em um neobanco descreveu essa mesma ordem: "Preparei minha planilha de avaliação com diferentes pesos e insights internamente... Vou me alinhar com as partes interessadas de outras áreas sobre os pesos... Assim que tivermos isso, fechamos a lista de finalistas."

1. As tarefas de monitoramento e os canais de pagamento cobertos

O que é. A cobertura de tarefas e canais refere-se a quais das suas demandas de monitoramento o software realiza hoje — decidindo sobre pagamentos no fluxo ou supervisionando a atividade após o ocorrido — e quais dos seus canais de pagamento ele consegue visualizar e agir sobre. O manual do FFIEC associa o nível de sofisticação à instituição: "A sofisticação dos sistemas de monitoramento deve ser ditada pelo perfil de risco do banco." Um banco receptor deve incluir créditos ACH recebidos, já que as regras da Nacha agora exigem que todas as RDFIs os monitorem.

As duas tarefas podem precisar de controles diferentes no mesmo canal. Um diretor global de conformidade de crimes financeiros em uma empresa de pagamentos disse: "Foque hoje em regras em tempo real para fraude, porque queremos ter a capacidade de ativar e desativar a função de bloquear em vez de apenas monitorar. Para lavagem de dinheiro, não faríamos isso."

O que perguntar ao fornecedor. Mostre-nos a atividade de um cliente em todos os nossos canais em uma única tela e diga-nos em quais canais você decide em tempo real e quais analisa após o ocorrido.

Como é uma resposta fraca. "Oferecemos suporte a todos os canais", sem uma demonstração real no seu mix de pagamentos, ou uma decisão em tempo real que cubra apenas um canal e não os outros que você mencionou.

2. Cobertura de tipologias que você possa mapear para sua própria avaliação de risco

O que é. A cobertura de tipologias é o quão bem os cenários e modelos de um produto se alinham às tipologias da sua própria avaliação de risco, e como essa cobertura se mantém atualizada. O mapeamento e a calibragem são testes separados; um sistema pode passar em um e falhar no outro. Um vice-presidente sênior e diretor de inteligência financeira de um banco regional disse sobre seu sistema atual: "Quando faço minha avaliação de cobertura, ele se mapeia muito bem... Mas, ao mesmo tempo, não é nada personalizável."

Os cenários que já vêm com o produto são apenas o ponto de partida. "Toda instituição deveria escrever regras personalizadas de acordo com seu modelo de negócio", disse uma oficial de PLD em uma fintech de pagamentos pré-pagos.

O que perguntar ao fornecedor. Mapeie sua biblioteca de cenários para a nossa avaliação de risco e mostre quais de nossas tipologias você cobre de forma nativa, quais precisaríamos configurar e quais teríamos que escrever do zero.

Como é uma resposta fraca. "Nossa IA detecta tudo", um mapa de cobertura sem opções para ajustar parâmetros para seus próprios clientes, ou cenários padrão apresentados como cobertura completa.

3. Os dados que ele pode usar e se você pode recuperá-los

O que é. O acesso aos dados envolve o que o software consegue ler — incluindo seus próprios dados, dados de terceiros e dados compartilhados ou de consórcio —, como ele vincula registros que pertencem ao mesmo cliente (resolução de entidade) e se você consegue exportar todos os seus dados de volta. A vinculação é fundamental porque um alerta só é útil com seu contexto: o dispositivo e a sessão, o comportamento normal da conta e o que está associado a ela.

Cada uma dessas partes pode definir a escolha de um fornecedor. Um gerente de risco de fraude em um banco comercial considerou os dados de consórcio do fornecedor atual como um de seus pontos mais fortes, pois os alertas gerados com base neles traziam muito menos falsos positivos. Para um oficial de conformidade em uma empresa de serviços de câmbio, "a resolução de entidade tem sido o divisor de águas". Já uma oficial de PLD em uma fintech de pagamentos pré-pagos queria os dados de volta: "Apenas me dê uma janela de dados aberta que nós mesmos faremos o download e o que for preciso com eles."

O que perguntar ao fornecedor. Quais de nossas fontes de dados você consegue ler desde o primeiro dia e quem desenvolve cada nova conexão? Como você vincula o mesmo cliente entre diferentes contas e produtos? Podemos exportar tudo, incluindo decisões e histórico de casos?

Como é uma resposta fraca. Serviços profissionais cobrados para cada novo campo, resolução de entidade descrita mas não demonstrada nos seus próprios registros, ou uma exportação que deixa de fora decisões ou histórico de casos.

4. Quem pode alterar a lógica de detecção e como uma alteração é testada

O que é. O controle de mudanças refere-se a quem pode alterar as regras e modelos de detecção, se uma alteração pode ser testada contra o histórico antes de ir para a produção, e como ela é aprovada e registrada. As regras continuam mudando mesmo quando os modelos realizam grande parte da detecção. Um diretor de risco em um banco digital disse: "Existem analistas que vão ajustar as regras o tempo todo porque nem tudo pode estar em um modelo."

Alterações não testadas vão direto para a fila de atendimento em tempo real. Um diretor de conformidade de um banco comunitário lembrou de uma alteração de regra feita diretamente em produção que gerou uma avalanche de alertas.

A configuração também precisa alcançar seus próprios programas e segmentos de clientes. Um diretor de risco em um banco patrocinador que atende gestores de programas pré-pagos disse: "Nós personalizamos nossas regras para cada programa." Um executivo de BSA/PLD de um banco com braço digital apontou a falta de segmentação como uma deficiência comum, pois uma rede nacional e um restaurante de bairro não são o mesmo tipo de cliente empresarial.

O que perguntar ao fornecedor. Mostre uma alteração de regra feita pela nossa equipe de risco sem a necessidade de seus engenheiros, testada contra nossos dados históricos, aprovada e registrada. Em seguida, mostre-nos o ambiente de testes em si.

Como é uma resposta fraca. Alterações que dependem dos engenheiros do fornecedor, segmentação limitada apenas a comercial e pessoal, ou um ambiente de testes que não permite testar de verdade. Depois que o ambiente paralelo de um fornecedor se mostrou incapaz de realizar testes, um especialista em sanções da OFAC em um banco comercial disse que "a expectativa versus a realidade acabou sendo bem diferente".

5. Por que cada alerta foi gerado, em termos que um investigador e um auditor possam entender

O que é. A explicabilidade no monitoramento de transações significa que o motivo de cada alerta ou decisão deve estar visível para o analista que o avalia e poder ser reconstruído mais tarde para um auditor, incluindo a versão da regra ou do modelo e os dados visualizados no momento. O manual do FFIEC estabelece essa expectativa claramente: "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." Na prática, o motivo deve chegar à fila do analista como códigos de justificativa.

As regras podem ser tão opacas quanto os modelos quando pertencem a terceiros. Um gerente de conformidade de BSA/PLD/OFAC em uma cooperativa de crédito disse que, quando os reguladores perguntam como os alertas são gerados, a equipe não consegue mostrar as regras específicas porque o fornecedor de monitoramento exibe apenas uma visão de alto nível. Um oficial de BSA em um banco comunitário com programa de parcerias bancárias disse: "Não entendemos como cada regra funciona... Acho que temos uma ideia do que as regras deveriam fazer, mas não de como fazem."

O que perguntar ao fornecedor. Busque um alerta de meses atrás e mostre-nos por que ele foi gerado, qual versão de regra ou modelo o disparou e os dados que estavam disponíveis no momento.

Como é uma resposta fraca. Uma visão de alto nível de regras que você não pode abrir, uma pontuação sem os motivos associados ou uma reconstrução que apenas a equipe do fornecedor consegue realizar.

6. O trabalho após o alerta, integrando fraude e PLD

O que é. O trabalho após o alerta é a gestão de casos e a transição entre fraude e PLD: como um alerta se torna um caso, como um caso de fraude vira um encaminhamento para PLD e quem é o responsável por cada decisão. As equipes de fraude e PLD devem olhar para o mesmo cliente e o mesmo comportamento, mas respondem a obrigações e padrões de prova diferentes. Dados compartilhados ajudam ambas as equipes, mas uma fila única e misturada de decisões cria um problema de governança.

Essa transição está se aproximando do momento do próprio pagamento. Um banco global descreveu a combinação da triagem de fraude e PLD no mesmo momento, no ato da transação, em vez de duas revisões feitas uma após a outra.

O que perguntar ao fornecedor. Mostre-nos um caso de fraude que se transforma em um encaminhamento de PLD, o que o investigador de PLD visualiza quando ele chega e quem é o responsável final pela decisão de enviar um relatório de atividade suspeita.

Como é uma resposta fraca. Uma fila unificada onde ninguém sabe quem é o responsável pela decisão, ou ferramentas separadas que não compartilham as informações do cliente, fazendo com que cada equipe tenha que reconstruir o mesmo cenário do zero.

7. As evidências geradas para seus validadores

O que é. Evidência de validação é a documentação, o acesso aos dados e o suporte de testes que os validadores do seu modelo precisam, pois mesmo um modelo fornecido por terceiros ainda é de responsabilidade da instituição para validação. As diretrizes revisadas de risco de modelo do Federal Reserve (SR 26-2), em sua seção sobre produtos de fornecedores, dizem que, como certos componentes podem ser proprietários, as organizações bancárias "podem não receber do fornecedor o código, os dados ou a metodologia subjacentes... No entanto, os princípios de gestão de risco de modelo continuam aplicáveis". A mesma seção acrescenta: "Um elemento importante da gestão de risco de modelo é a validação de produtos de fornecedores, seja por equipes internas ou externas."

O manual do FFIEC também prevê que "a metodologia de programação e a eficácia do sistema de monitoramento devem ser validadas de forma independente". Sistemas em camadas tornam isso mais difícil. Um vice-presidente sênior de gestão de risco de modelo em um banco regional descreveu isso como "uma caixa preta em cima de outra caixa preta, sabe? Não há transparência nenhuma na tomada de decisão que está ocorrendo".

A linha entre uma regra e um modelo também se confunde na prática, de modo que os validadores precisam visualizar ambos. Um gerente de análise de risco em um banco regional descreveu o uso de análise de agrupamento (cluster) para encontrar padrões, convertendo depois os resultados em regras e tabelas, porque o sistema de monitoramento só conseguia rodar regras.

O que perguntar ao fornecedor. Que tipo de documentação, dados e acesso a testes nossos validadores receberão e como cada modelo é monitorado contra desvios (drift) após a entrada em operação?

Como é uma resposta fraca. "A metodologia é proprietária", sem oferecer nenhuma alternativa. Como realizar a validação em si é abordado em um guia sobre validação de modelos de PLD.

8. O custo de operação, não apenas de aquisição

O que é. O custo de operação de um software de monitoramento de transações envolve tudo o que vai além da licença: a conexão com seus sistemas, o número de fornecedores dos quais cada processo depende, o cronograma dos contratos e quem controla o orçamento. A integração é paga por fornecedor, e algumas integrações falham. Um proprietário técnico de produto para plataformas de fraude e identidade em um grande banco regional disse: "Houve cenários em que percebemos que algo não estava se integrando bem. Tivemos que abandonar e partir para outra solução."

O número de fornecedores e contratos traz custos adicionais. Um líder de risco em um banco regional disse: "Não gosto de ter muitos fornecedores atrelados a um único processo." Um diretor de operações de crimes financeiros em um grande banco regional apontou contratos "com cronogramas diferentes" e acrescentou que "no fim das contas, a área de tecnologia é quem controla nosso orçamento".

O que perguntar ao fornecedor. Qual é o custo total para conectar isso aos nossos sistemas e mantê-lo rodando, o que é cobrado separadamente e o que nossa própria equipe precisará desenvolver ou manter?

Como é uma resposta fraca. Cobranças adicionais por conexão descobertas após a assinatura do contrato, ou serviços de integração que aparecem apenas como escopo aberto de serviços profissionais.

9. Se ele vai se provar com seus dados antes de você assinar

O que é. A prova com dados reais é a disposição do fornecedor de rodar o software com seu histórico e, depois, em modo de teste paralelo (shadow) ao lado do seu processo ativo, antes de você assinar. O teste só é útil se o fornecedor mostrar os casos que o software perdeu, bem como os que ele detectou. Peça para ver o ambiente onde o teste será executado, pois o alerta do critério 4 também se aplica aqui.

O que perguntar ao fornecedor. Rode o sistema com nossos alertas históricos e em modo paralelo na nossa fila ativa, e mostre-nos tanto as falhas quanto os acertos.

Como é uma resposta fraca. Uma demonstração realizada apenas com dados do próprio fornecedor, ou resultados apresentados de forma agregada, sem que você possa inspecionar os casos individualmente. Como realizar esse teste, avaliando a qualidade do alerta e o processo de trabalho do investigador juntos, é abordado em um guia separado sobre como avaliar plataformas de monitoramento de transações de PLD com seus próprios dados.

Onde a Oscilar se encaixa, avaliada pelos mesmos critérios

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. Os agentes podem rodar como uma camada independente sobre a infraestrutura que você já possui ou como parte da plataforma unificada, o que ajuda na escolha entre manter o sistema atual, aplicar uma sobreposição ou substituí-lo.

Em relação à lógica de detecção e explicabilidade, a Oscilar descreve sua abordagem para o monitoramento de PLD em bancos como uma combinação de regras configuráveis com padrões comportamentais, detecção de anomalias, risco do cliente, contexto de rede e priorização de alertas, preservando controles explicáveis e a revisão humana. A Oscilar mantém uma trilha de auditoria completa para cada decisão com justificativas salvas, desenhada para manter o controle humano no processo.

A especificação de plataforma da Oscilar prevê decisões em menos de 100 milissegundos, conforme publicado no comunicado de imprensa da Nacha em 11 de dezembro de 2025. Esse número é uma especificação fornecida pela Oscilar e não um benchmark independente, por isso meça-o com seu próprio tráfego durante o período de teste paralelo. A frente de fraude da plataforma é descrita em monitoramento de fraude em transações.

A Chartis Research incluiu a Oscilar no ranking FCC50 de 2026, com vitórias nas categorias de Inovação em IA de Agentes e Personalização Low-Code/No-Code. Esse é o reconhecimento de uma empresa de análise de mercado e não reflete a classificação deste guia.

Avalie a Oscilar com base no critério 9 como qualquer outro fornecedor: peça o teste histórico e o período de teste paralelo com seus próprios dados, e exija ver as falhas de detecção. O que definir antes de mudar de sistema, uma vez feita a escolha, é abordado em um guia de compras de software de PLD separado.

Os nove critérios resumidos

Perguntas frequentes

O que os compradores devem avaliar ao comparar softwares de monitoramento de transações?

Os compradores devem avaliar o software com base nas tarefas de monitoramento e canais de pagamento cobertos, alinhamento de tipologias com sua avaliação de risco, capacidade de uso e retorno de dados, controle de alterações, explicabilidade de alertas, transição de casos entre fraude e PLD, evidências para validação de modelos, custo total de operação e testes com dados reais antes da contratação. Defina o peso desses critérios antes de qualquer demonstração e faça as mesmas perguntas a todos os fornecedores.

Quais critérios de avaliação são mais importantes para instituições financeiras reguladas?

Para uma instituição financeira regulada, os critérios que um auditor irá testar têm o maior peso: explicabilidade dos alertas, como as alterações na lógica de detecção são testadas e registradas, o mapeamento de tipologias em relação à avaliação de risco e as evidências fornecidas para os validadores de modelos. O manual do FFIEC prevê que a gestão documente e explique seus critérios de filtragem e limites, e que o sistema de monitoramento seja validado de forma independente. O peso exato de cada critério deve acompanhar o perfil de risco de cada instituição, o qual, segundo o manual, deve ditar o nível de sofisticação do monitoramento.

O monitoramento de fraude em tempo real é a mesma coisa que o monitoramento de transações de PLD?

Não. O monitoramento de fraude em tempo real decide, enquanto o pagamento está em processamento, se deve bloqueá-lo, retê-lo ou autorizá-lo antes que o dinheiro saia da conta. Já o monitoramento de transações de PLD analisa o comportamento do cliente ao longo do tempo, gera alertas para investigação e apoia a elaboração de relatórios de atividades suspeitas após o ocorrido. Ambos podem compartilhar dados e uma visão unificada do cliente, mas respondem a obrigações distintas, por isso uma plataforma que execute ambos deve manter as decisões e a autonomia de cada equipe separadas.

Por que esta lista não cita nenhum fornecedor concorrente?

Esta lista não cita fornecedores porque a Oscilar, que a desenvolveu, vende software de monitoramento de transações, e uma classificação publicada por quem vende não seria neutra. Ao não nomear produtos, o guia se mantém focado em critérios que o comprador pode aplicar a qualquer fornecedor, incluindo a própria Oscilar. A lista de finalistas deve surgir da ponderação de pesos do próprio comprador e das respostas enviadas por cada fornecedor.

Como a Oscilar se posiciona diante desses critérios?

A Oscilar se avalia com base nos mesmos nove critérios em uma seção dedicada deste guia, utilizando apenas informações comprovadas, como a trilha de auditoria completa por decisão com justificativas salvas. O comprador deve tratar essas informações como premissas a serem testadas. Peça à Oscilar o mesmo teste histórico de alertas e período paralelo na fila ativa exigido de qualquer outro fornecedor no critério 9.