Consegue justificar os seus resultados? 6 perguntas para testar a sua monitorização de transações de AML

Um responsável de BSA disse-nos recentemente que o seu CEO lhe ligou duas vezes no dia em que saíram as últimas notícias sobre sanções de AML. Em todo o setor, as equipas de conformidade e os executivos estavam, sem dúvida, a perguntar-se: "Será que poderíamos ser nós?"

Numa única semana, duas ações sancionatórias pesadas de AML destacaram um desafio crucial do setor. Ambas as instituições tinham tecnologia implementada, mas os sistemas falharam. O problema foi uma lógica de monitorização que ninguém conseguia explicar, testar ou defender totalmente.

Isto reflete uma mudança que tenho vindo a acompanhar há algum tempo. As políticas e os procedimentos continuam a ser importantes, mas os reguladores estão a ir muito além deles. Estas coimas mostram claramente que o mero cumprimento pró-forma já não é defensável. 

Quais são os seus limites? São adequados? O que esteve na sua origem? 

O foco numa abordagem baseada no risco visa garantir que cada programa se ajusta à sua instituição, e os reguladores estão a verificar isso minuciosamente, porque cumprir requisitos no papel não é tomar decisões. O risco é exclusivo de cada instituição, e o programa de AML também deve sê-lo.

Quer se trate das suas transações diretas, do volume de um parceiro de BaaS ou da lógica de terceiros, o canal bancário é seu, a licença é sua e a responsabilidade é sua.

Digo algo semelhante à citação acima há anos. Se utiliza um fornecedor, gere um programa de BaaS ou subcontrata parte do seu trabalho de conformidade, tem de ser capaz de olhar um regulador nos olhos e explicar exatamente o que está a acontecer. 

Dizer que "outra pessoa trata disso" não serve, nem tão-pouco uma resposta vaga. 

É por isso que reuni seis perguntas às quais qualquer líder de AML deve ser capaz de responder sobre o seu próprio programa.

Resumo: O que significam as recentes sanções de AML para o seu programa de monitorização de transações?

As recentes sanções apontam para a mesma lacuna: uma lógica de monitorização que a instituição não conseguiu explicar nem defender. Os reguladores esperam que justifique cada limite, regra e decisão apoiada por IA, em vez de apenas mostrar que existem controlos. Essa responsabilidade recai sobre a sua instituição, mesmo quando existe um fornecedor ou parceiro envolvido.

• Explique cada limite e regra, incluindo os que não criou. A lógica predefinida ou de fornecedores concebida para o programa de outra pessoa continua a ser da sua responsabilidade defender.

• Deixe que os seus dados orientem os ajustes, não a sua equipa. Regras personalizadas e testes retrospetivos reduzem o ruído com base em motivos que pode documentar.

• Feche o ciclo quando os testes detetarem um problema, com uma correção testada e um registo de aprovações.

• Adequar a cobertura à sua avaliação de risco em todos os produtos, geografias e clientes.

• Identifique atividades suspeitas por si próprio. O contacto das autoridades deve confirmar a sua monitorização, não substituí-la.

• Exija o mesmo padrão à IA. Se não consegue ver como chegou a uma conclusão, não pode defendê-la.

1. Consegue explicar cada limite e regra de monitorização de transações, incluindo os que não criou?

As conclusões descrevem limites definidos por intuição e sem dados de suporte, mantidos durante anos, bem como regras que suprimiam alertas sem uma verdadeira governança. Ninguém conseguia justificar a razão daqueles valores. Este é o perigo de um programa estático. 

Vejo a mesma lacuna de outro prisma: instituições a executar regras que nunca foram adaptadas a si. Por vezes, é um modelo predefinido que foi ativado e nunca ajustado. Noutras, é um fornecedor de "caixa negra" cuja lógica foi concebida para o programa de outra pessoa. Um dos nossos clientes descreveu um fornecedor anterior desta forma: "Só se pode alterar o limite, mais nada. Não se pode mudar uma regra."

Regras predefinidas são um bom ponto de partida. Nós também as temos. Mas devem ser apenas uma base, nunca a solução final. Cada regra deve ser ajustada aos limites do seu segmento, clientes e produtos.

Na prática, um programa transparente ("caixa de vidro") proporciona-lhe:

• Lógica de regras que o seu responsável de BSA consegue ler sem ligar a um fornecedor ou cientista de dados

• Uma justificação documentada para cada limite

• Testes retrospetivos antes de qualquer alteração entrar em produção

• Um histórico de versões que mostra exatamente o que estava ativo numa determinada data
  
  

"Um regulador vai perguntar-me… como é que o sistema determinou isto? E se não o tiver por escrito, não o conseguirei defender." - Líder de BSA, banco comunitário

2. A sua monitorização de AML é orientada pelos seus dados ou pela dimensão da sua equipa?

Uma das conclusões que me marcou descreve uma monitorização desenhada em função do número de analistas disponíveis, mantendo os recursos de conformidade no mínimo. Compreendo a pressão. Todas as equipas com quem trabalhei já tiveram mais alertas do que pessoas a dada altura. Mas quando a equipa dita os limites, a cobertura passa a ser apenas o que sobra.

Ajustar para reduzir o ruído é bom. O motivo pelo qual o faz é o que importa. Regras personalizadas para o seu portfólio, combinadas com testes retrospetivos sobre os seus próprios dados históricos, mostram que regras detetam riscos reais e quais apenas geram trabalho. Dados sobre a eficácia das regras, como a conversão em relatórios de atividades suspeitas (SAR), mostram onde focar a atenção. Essa é uma decisão para fortalecer o seu programa de BSA, não uma manobra para gerir volumes com base no número de colaboradores, e é algo que pode documentar.

Depois, há a primeira análise. Um agente de revisão de alertas de AML pode pré-analisar cada alerta, reunir o contexto e sugerir uma decisão fundamentada, cabendo ao seu analista a palavra final. Regras ajustadas em conjunto com um agente na primeira análise juntam o útil ao agradável: as regras mantidas ganham mais relevância e a sua equipa foca-se no risco real em vez do ruído.

"Com dados quantitativos, não há como refutar… isso cria capacidade de defesa." - Líder de conformidade, empresa global de pagamentos

3. Quando os testes ao modelo de AML detetam um problema, o que acontece a seguir?

As conclusões recentes descrevem testes que apontaram problemas significativos, aos quais não se seguiu qualquer ação concreta. Registar uma preocupação não é o mesmo que resolvê-la.

Se nunca trabalhou na banca, deixe-me dar-lhe uma perspetiva interna. Um problema começa muitas vezes por ser uma observação. Se não for corrigido, passa a inconformidade. Nessa altura, assume-se um plano de resolução, incluindo o que vai mudar, como e até quando. Assumir o compromisso é a parte fácil. Concretizá-lo é onde os programas costumam falhar.

Numa função anterior, eu não conseguia testar alterações às regras de todo. Tudo tinha de ir direto para produção. 

Se está a tentar corrigir algo de forma cuidadosa, não é essa a situação em que quer estar.

Imagine que uma regra está a inundar a sua fila com falsos positivos e a criar atrasos. Uma abordagem transparente ("caixa de vidro"):

• Usa os seus dados para determinar a correção adequada

• Testa a alteração em paralelo antes de afetar decisões reais

• Implementa com um registo de aprovação, sem esperar semanas por um pedido de alteração

• Entrega a documentação à auditoria interna ou ao regulador

O que se pretende evitar é a justificação: "desligámos porque era trabalho a mais".

A transparência também ajuda após a correção. Se se comprometeu a resolver o atraso em seis meses, um painel com faixas de antiguidade permite-lhe a si, aos auditores e à administração acompanhar a redução do trabalho pendente em tempo real. A análise com IA permite fazer perguntas em linguagem corrente sobre o programa e consultar a lógica por trás de cada resposta.

4. A sua cobertura abrange todos os produtos da sua avaliação de risco de AML?

As ações recentes revelaram falhas de cobertura evidentes: monitorização limitada de ordens de pagamento e outros títulos negociáveis, monitorização fraca de cartões de crédito e um foco em produtos de depósito menores em detrimento de uma operação de cartões muito maior.

A cobertura do programa começa na avaliação de risco. Deve abranger todo o leque de produtos, tipologias, serviços, riscos geográficos e portfólio de clientes. A sua monitorização de transações deve refletir diretamente estas conclusões. Por exemplo, um banco no sul do Texas pode ponderar a sua atividade de ordens de pagamento de forma diferente de outros serviços devido a exigências regulamentares que impõem maior escrutínio. Ainda assim, os restantes produtos requerem uma avaliação cuidada e uma monitorização adaptada. A área de conformidade não pode apenas reagir ao tema do momento. Manter a visibilidade sobre todas as tipologias e produtos garante que a avaliação de risco cobre todas as áreas, oferecendo uma cobertura dinâmica e abrangente.

Um programa transparente organiza as regras por tipologia e mapeia-as na sua avaliação de risco, permitindo demonstrar a cobertura numa visão única em vez de ter de reunir dados de vários sistemas quando o regulador o solicitar.

5. Quem está a identificar a atividade suspeita: a monitorização de transações ou as autoridades?

Num caso recente, mais de um terço das investigações começou com acontecimentos externos, como intimações, pedidos das autoridades ou solicitações de outras instituições financeiras, e não através da monitorização da própria instituição.

Note-se que ser contactado pelas autoridades é perfeitamente normal. Em funções anteriores, colaborei com a SEC, IRS, DOJ e autoridades locais, e via sempre com agrado esses contactos, sobretudo relativos a atividades que já tinha comunicado. Esse contacto deve confirmar o que a sua monitorização identificou. Não deve ser a forma principal de descobrir atividades suspeitas. 

Ter monitorização de transações automatizada não é o mesmo que ter monitorização eficaz. Se não deteta atividade, serve apenas para criar trabalho. Avalie a eficácia de deteção regra a regra, saiba de onde vêm os seus casos e acompanhe as tendências ao longo do tempo para ser proativo e não reativo.

6. Consegue explicar a IA utilizada no seu programa de AML?

A governança de IA é um tema central para as equipas de conformidade neste momento, e por bons motivos. Estas equipas sabem que têm de defender cada decisão. Não podem defender o que não conseguem ver. Alguns grandes bancos estão mesmo a bloquear agentes de IA por não conseguirem explicar a lógica em que assentam.

"A nossa equipa de gestão de risco de modelos quer ver o que está dentro da caixa negra." - Responsável de Governança do Programa de BSA, banco regional

A solução não é evitar a IA, mas sim exigir-lhe o mesmo rigor aplicado às regras. O modelo que vejo funcionar, e o mais procurado pelos nossos clientes, é a intervenção humana (human in the loop): o agente recomenda uma ação fundamentada, uma pessoa decide e cada alteração manual fica registada. 

A automação pode crescer à medida que a confiança aumenta. Quando um regulador perguntar como foi tomada uma decisão, pode mostrar os dados utilizados pelo agente, o que ele sugeriu e quem tomou a decisão final.

A monitorização de AML transparente é a forma de responder a um regulador

Nenhuma destas questões é nova. O que mudou foi o nível de exigência dos reguladores e a falta de espaço para respostas como "o sistema funciona assim".

A monitorização transparente ("caixa de vidro") é a resposta quando um regulador pergunta como o sistema chegou a determinada conclusão. Não se trata apenas de uma funcionalidade ou de um visto formal na lista, mas sim de mostrar o trabalho feito em vez de esperar que outra pessoa o tenha feito bem. 

No fim de contas, a licença e a responsabilidade são suas; portanto, cada limite, regra e decisão apoiada por IA deve ser algo que consiga explicar e defender por si mesmo.

Se quer ver como isto funciona na prática, conheça a abordagem da Oscilar à monitorização de transações de AML.

Perguntas Frequentes

O que significa a monitorização de transações de AML em "caixa de vidro"?

Significa que os responsáveis pelo programa de AML conseguem ver e explicar o seu funcionamento: a lógica de cada regra, a razão de cada limite definido, o que mudou e quando, e como se chegou a qualquer decisão apoiada por IA. O oposto é a "caixa negra", onde os alertas surgem sem que a instituição consiga explicar como foram gerados.

Porque é que os reguladores valorizam a explicabilidade nos programas de AML?

Um programa baseado no risco deve ajustar-se aos riscos próprios da instituição. Os reguladores avaliam isso perguntando como foram definidos os limites, como foram ajustadas as regras e como são medidos os resultados. Se uma instituição não consegue explicar estas escolhas com documentação, não consegue demonstrar que o programa funciona de acordo com as suas políticas.

Um banco é responsável pelos controlos de AML executados por um fornecedor ou parceiro de BaaS?

Sim. Um banco pode recorrer a fornecedores e parceiros, mas o programa de BSA/AML e a respetiva responsabilidade continuam a ser da instituição titular da licença bancária. Por isso, o banco tem de compreender e ser capaz de defender qualquer lógica em que se apoie, incluindo a desenvolvida por terceiros.

Como podem os bancos reduzir os falsos positivos de AML sem aumentar o risco?

Faça ajustes com base em dados e não no número de analistas. Personalize as regras para os seus produtos e clientes, teste as alterações com dados históricos antes de as implementar, acompanhe a eficácia das regras (como a conversão em relatórios de atividades suspeitas) e documente os motivos de cada alteração. Isto reduz o ruído com base em justificações que pode defender.

Os bancos podem utilizar IA na conformidade de AML se os reguladores exigirem explicabilidade?

Sim, desde que a IA seja explicável e devidamente gerida. Uma abordagem habitual envolve intervenção humana: o agente de IA recomenda uma ação com a respetiva justificação, um analista toma a decisão e todos os resultados ou alterações manuais são registados para efeitos de auditoria e inspeção regulamentar.