FRAML: Unifique Fraude e PLD Sem Diluir Responsabilidades

Última atualização: Setembro de 2026

As equipas de prevenção de fraude e de AML olham para os mesmos clientes, as mesmas contas e as mesmas transações e, durante a maior parte da última década, fizeram-no em salas separadas com ferramentas separadas. Reduzir esta distância é uma das vitórias mais claras ao alcance de uma função de combate ao crime financeiro. Contudo, o termo "unificado" tem muito peso na maioria das conversas sobre o assunto, e a versão que corre mal é aquela que ninguém definiu.

A resposta curta: unifique a camada de sinais, não a responsabilidade.

Resumo

• FRAML significa tratar a fraude e a prevenção do branqueamento de capitais como um único espaço de problemas — mas o termo abrange três coisas diferentes, que não representam uma decisão única.

• A fraude e o AML partilham o cliente, o comportamento e os sinais subjacentes, pelo que o argumento a favor de uma camada de dados partilhada é forte.

• Não partilham a obrigação, a expectativa de supervisão, o prazo ou o nível de prova exigido.

• Unifique os dados. Unifique em grande parte a deteção, com etiquetas separadas e validação separada. Não funda decisões e responsabilidade.

• O cenário de falha é uma fila de espera fundida: o trabalho de conformidade acaba por ser gerido com base nas métricas de produtividade da fraude, porque é isso que o painel de controlo mostra.

• Faseie o processo: primeiro os dados, depois a deteção e, por último, o modelo operacional — e apenas quando houver um motivo que vá além da eficiência.

O que é o FRAML?

O FRAML é a prática de tratar a fraude e o branqueamento de capitais como um único espaço de problemas e não como dois, com base no facto de ambos rastrearem atividades ilegítimas que se movem através dos mesmos clientes e das mesmas transações. Na prática, o termo abrange três coisas diferentes: dados partilhados, deteção partilhada ou uma equipa fundida.

Estas três vertentes não constituem a mesma decisão, e o resto deste artigo depende de as mantermos separadas.

Por que razão a fraude e o AML estão a convergir agora

Esta convergência não é uma invenção dos fornecedores de software. É um esforço de todo o setor e tem dois motores concretos.

O primeiro é que as tipologias se fundiram na prática. Uma conta de "mula" é um problema de fraude e um problema de branqueamento ao mesmo tempo, na mesma transação — os fundos são obtidos enganando alguém e depois movimentados para ocultar a sua origem. Tratar isto como duas investigações de duas coisas diferentes significa ter duas equipas a reconstruir a mesma história com metade das provas cada uma.

O segundo é o fator tempo. Os pagamentos em tempo real reduziram os prazos. Uma análise que antes era feita calmamente após a liquidação tem agora de ser feita no momento da transação ou não será feita de todo. Numa conversa sobre este exato tema, um banco global descreveu a mudança como a combinação do rastreio de fraude e de AML no mesmo momento — o momento da transação — em vez de duas análises sequenciais. Essa simultaneidade é o mecanismo chave. A partir do momento em que ambas as perguntas têm de ser respondidas no mesmo instante, ter duas visões separadas do cliente deixa de ser uma ineficiência e passa a ser uma limitação.

Este é também um tipo de programa ativo em vez de uma mera aspiração. As instituições referem-se aos seus próprios esforços de FRAML como programas internos específicos, com orçamentos e trajetórias definidos, e reorganizam as suas funções de combate ao crime financeiro em torno deles.

O que a fraude e o AML partilham genuinamente

Vale a pena ser claro sobre o quão forte é o argumento a favor da convergência, porque as cautelas apresentadas mais adiante neste artigo não servem para o contrariar.

Partilham o sujeito. O mesmo cliente, a mesma conta, o mesmo comportamento, observados por duas funções que historicamente não conseguiam ver a perspetiva uma da outra.

Partilham a matéria-prima. Dispositivo, identidade, rede, velocidade, contraparte — os sinais que indicam algo útil a um modelo de fraude são, em grande parte, os mesmos sinais que indicam algo útil a um sistema de monitorização, e nenhuma das funções os gera isoladamente. A mesma base de provas serve para analisar um pagamento em tempo real e para decidir se esse pagamento faz parte de um padrão que vale a pena reportar.

E partilham o desafio analítico: separar o que é invulgar do que é ilegítimo. É por isso que as técnicas de deteção se transferem genuinamente entre os dois domínios, e por isso uma equipa que desenvolveu uma boa infraestrutura de variáveis de um lado raramente começa do zero no outro.

Portanto, o argumento a favor de uma camada de dados partilhada não é uma posição de compromisso intermédio. É o argumento mais forte de todo este debate, e a maior parte do valor de um programa FRAML reside nele.

O que eles não partilham

Aqui está a parte que o entusiasmo costuma ignorar.

A natureza da obrigação é diferente. Uma perda por fraude é dinheiro da própria instituição, e esta decide quanto está disposta a aceitar. A deteção de branqueamento de capitais é um dever de reporte — uma obrigação perante o exterior, relativa à conduta de terceiros, cumprida ao comunicar a uma autoridade o que foi observado. Uma é uma decisão comercial sobre o próprio balanço. A outra é uma responsabilidade perante terceiros.

A avaliação é diferente. Aplicam-se expectativas de supervisão diferentes a cada uma, pelo que o histórico que um auditor irá solicitar também será diferente.

O prazo é diferente. Uma decisão sobre fraude é tomada em milissegundos, à velocidade das máquinas, e é normalmente reversível — pode libertar uma transação retida ou anular um bloqueio. Uma decisão de reporte corre a um ritmo mais lento e não é reversível da mesma forma.

O nível de prova exigido é diferente. As decisões sobre fraude baseiam-se em probabilidades e aceitam deliberadamente erros em ambas as direções, porque o custo de cada erro é conhecido e pode ser ajustado. Já uma decisão de reporte é um julgamento ponderado que tem de conter uma justificação fundamentada e documentada na qual uma pessoa possa apoiar-se no futuro.

Note que a consequência de confundir as duas coisas tem um sentido único. Um padrão de nível AML aplicado a decisões sobre fraude torna-se lento e dispendioso. Já um processo de fraude que absorve silenciosamente uma decisão de reporte constitui uma falha de controlo, não uma eficiência.

As três camadas que as pessoas referem como "unificadas"

Os compradores chegam a esta questão já meio conscientes da ambiguidade. Numa avaliação recente, uma empresa de serviços financeiros de consumo estruturou o seu próprio processo como uma questão de três vias — estariam a olhar para uma solução de AML, uma solução de fraude ou uma solução de FRAML — e de seguida fez uma pergunta muito mais incisiva: até que ponto queriam realmente combinar as análises realizadas em cada lado?

Esta segunda pergunta é a que realmente importa, e divide-se em três camadas.

Camada um: dados. Unifique-os. Não há nenhum argumento válido para ter duas visões do mesmo cliente. A maior parte do valor está aqui, o risco de governação é quase nulo e a mudança é reversível.

Camada dois: modelos e deteção. Unifique em grande parte. As variáveis e os sinais partilhados transferem-se genuinamente, com uma ressalva que deve ser gerida e não apenas presumida: as populações de dados rotulados são diferentes. Um modelo treinado em resultados de fraude confirmada não passa a ser automaticamente um modelo de monitorização, porque "fraude confirmada" e "reportado como suspeito" não são o mesmo evento — sendo o segundo muito mais raro e muito mais dependente da mediação humana. Infraestrutura partilhada, sim. Etiquetas partilhadas, não.

Camada três: decisões e responsabilidade. Não funda. É aqui que as obrigações divergem, e fundir esta camada é o que gera confusão na governação.

A maior parte da desilusão com os programas FRAML surge por se tratarem estas três camadas como uma decisão única, concordando com ela em princípio, para depois descobrir na terceira camada o que realmente se aceitou.

Onde a consolidação simplista falha

A falha tem um momento reconhecível. Num workshop sobre um processo unificado, uma empresa de pagamentos norte-americana deparou-se com isto em direto: como o modelo coloca os investigadores de fraude também a analisar casos sob o ponto de vista de AML, o destino final do trabalho passa a ser um relatório de atividade suspeita — e, a partir daí, ninguém na sala foi capaz de dizer qual deveria ser o processo de trabalho.

Essa questão resume todo o problema numa única frase. Um investigador de fraude que chega a uma decisão de reporte é uma questão de governação, não de encaminhamento, e nenhum desenho de processo resolve isso.

Três aspetos falham especificamente:

• Quem assume a responsabilidade do reporte. Uma fila de espera fundida pressupõe um responsável fundido, e a decisão de reporte é precisamente aquela que tem de ter um responsável nominal.

• O que acontece a um caso que se enquadra em ambos. Um potencial estorno que também é candidato a reporte tem dois desfechos possíveis, e um único registo de caso com um único campo de resolução força alguém a escolher um deles.

• Com base em que métricas a equipa fundida é gerida. Este é o vilão silencioso. Ao fundir a fila de espera, o trabalho de conformidade acabará por ser gerido com base nas métricas de produtividade da fraude, porque a produtividade é o que o painel de controlo mostra. Ninguém decide isto. Simplesmente acontece, de forma silenciosa, e é exatamente isso que o torna perigoso.

Como funciona a unificação mantendo a responsabilidade separada

A solução não é "voltar a ter duas equipas". É ter uma visão única do cliente com dois responsáveis pelas decisões.

A camada partilhada é o que ambas as funções veem. Os direitos de decisão permanecem na função que carrega a obrigação legal. Um caso que se enquadra genuinamente em ambas as vertentes é tratado duas vezes de propósito, com cada função a chegar à sua própria conclusão com base nas provas partilhadas, em vez de herdar a conclusão da outra — o que é o oposto de trabalho duplicado, visto que a parte dispendiosa de uma investigação é reunir as provas, não lê-las.

O que torna isto prático em vez de burocrático é o registo. Um registo de auditoria completo por decisão com a fundamentação guardada, com intervenção humana planeada desde o início (human-in-the-loop) e desenhado para cumprir as normas regulamentares, permite que cada função veja como a outra chegou à sua conclusão sem ficar vinculada a ela. A fundamentação da equipa de fraude passa a ser uma prova para o analista de conformidade, e não um veredicto que lhe é imposto.

As ferramentas subjacentes podem ser totalmente partilhadas. Uma plataforma unificada — com dados em tempo real, inteligência de dispositivos e de comportamento, regras e gestão de casos num único sistema, com agentes nativos da própria plataforma — constitui uma camada partilhada de sinais e de ferramentas. Não é uma decisão fundida, e não deve ser apresentada ao conselho de administração do leitor como tal.

A diferença prática entre um programa convergente e um programa confuso resume-se a isto: no primeiro, as transições entre fraude e conformidade são planeadas, identificadas e registadas. No segundo, são apenas implícitas.

Como planear a transição por etapas

Aqui, a sequência importa mais do que a velocidade, porque as camadas diferem na facilidade com que podem ser revertidas.

1. Primeiro, os dados. É a etapa de maior valor, menor risco de governação e reversível. Se um programa não fizer mais nada, isto já o justifica. A decisão de integração (onboarding) é frequentemente o ponto de partida mais claro, porque os sinais recolhidos na abertura de conta são os mesmos que ambas as funções vão querer em todas as transações seguintes.

2. Depois, a deteção partilhada, gerindo explicitamente a ressalva das etiquetas em vez de a ignorar. Variáveis e ferramentas partilhadas; objetivos e validações separados.

3. Por fim, e apenas se houver uma razão além da eficiência, o modelo operacional. Defina por escrito quem é responsável por qual decisão antes de alterar o que quer que seja na disposição das equipas.

Aplica-se um teste em cada etapa. Se um auditor perguntar quem tomou esta decisão e com que base, a resposta continua a ser um nome individual e uma fundamentação registada? Enquanto for, está a unificar a camada de sinais. Quando deixar de ser, começou a fundir a responsabilidade e deve ser capaz de explicar o motivo.

Se a etapa de partilha de dados é a que está a planear agora, vale a pena analisar o que um sistema de deteção consolidado realmente precisa de fazer antes de definir o seu âmbito.

Uma questão relacionada — até que ponto o contexto partilhado reduz realmente os falsos positivos e o que é necessário para lá chegar sem aumentar as perdas por fraude — merece uma análise própria. O mesmo se aplica à escolha entre regras e modelos na camada dois, que é o mesmo debate, mas a um nível mais técnico.

Perguntas frequentes

O que significa a sigla FRAML?

FRAML é a junção de fraude e AML (anti-money laundering / prevenção do branqueamento de capitais). Refere-se ao tratamento destas duas áreas como um único espaço de problemas, com dados partilhados e, frequentemente, ferramentas partilhadas, em vez de duas funções separadas com visões distintas do mesmo cliente.

Qual é a diferença entre fraude e AML?

A fraude diz respeito à perda financeira da própria instituição: alguém retira dinheiro que não lhe pertence e a instituição decide que nível de risco está disposta a absorver. O AML é um dever de reporte perante o exterior sobre a conduta de terceiros. Essa diferença na obrigação molda tudo o resto — diferentes expectativas de supervisão, diferentes prazos e diferentes níveis de prova exigidos para cada decisão.

Quem submete o relatório de atividade suspeita num modelo unificado de fraude e AML?

Estruturalmente, o envio do relatório continua a cargo da função que detém a obrigação legal de reporte, independentemente das ferramentas partilhadas que existam por baixo. Unificar os dados e a deteção não transfere essa responsabilidade, e um caso identificado por um modelo de fraude continua a chegar à decisão de reporte através do julgamento e registo próprios da função de conformidade. Confirme os requisitos específicos aplicáveis à sua instituição com o seu departamento jurídico ou de conformidade.

A combinação de fraude e AML reduz os falsos positivos?

Na camada de dados, geralmente sim — mais contexto em cada decisão significa menos alertas gerados para comportamentos que outro sistema já conseguiria explicar. No entanto, fundir as filas de espera de trabalho não produz esse efeito e pode até ocultá-lo, porque um volume partilhado de alertas esconde de que lado vem realmente o ruído. O ganho provém do sinal partilhado, não da partilha de pessoal.

O que deve um banco unificar primeiro?

Os dados. Uma visão única do cliente, da conta e da transação, disponível para ambas as funções. Traz a maior parte do valor, quase nenhum risco de governação e pode ser revertida se não funcionar. Tudo o resto num programa FRAML torna-se mais fácil de avaliar quando ambos os lados estão a olhar para a mesma imagem.