Sistema de monitorização de transações AML

Um sistema confiável precisa de tudo isto:

• Dados de entrada limpos. A maioria das falhas de monitoramento começa aqui. Um cenário não consegue detectar o que nunca recebeu, portanto a completude e o mapeamento dos dados importam mais do que o nível de sofisticação da detecção.
• Configuração que reflita o seu risco. Cenários, limites e segmentos de clientes definidos segundo a sua própria avaliação de risco, e não segundo padrões do fornecedor, com controle de mudanças e aprovação independente para cada alteração.
• Detecção que vá além de transações isoladas. Regras para tipologias conhecidas, análise comportamental para padrões que as regras não conseguem expressar e análise de rede para revelar ligações entre contas. Alertas também podem vir de fora do sistema, por exemplo, quando um resultado de screening leva a uma revisão retrospetiva da atividade. Seja qual for o método, você precisa ser capaz de explicar por que um alerta foi disparado.
• Gestão de casos. Um alerta é gerado e depois investigado. Suspeita é aquilo a que a investigação chega, não aquilo que a desencadeia.
• Uma rota clara de escalonamento. A equipa precisa saber como levantar uma preocupação, e o seu MLRO ou compliance officer deve ser quem decide se isso vai para as autoridades.
• Relatórios adaptados aos seus mercados. Cada FIU tem o seu próprio formato, portal e prazo. Alguns regimes exigem autorização antes que você possa prosseguir com uma transação já reportada. E em todo lugar é proibido informar ao cliente que um relatório foi apresentado, ao mesmo tempo em que você é protegido de responsabilidade quando reporta de boa-fé.
• Uma trilha de auditoria e meios para ajustar. Qual cenário foi acionado, com base em quais dados, quem analisou, o que decidiu e por quê, e quem aprovou cada mudança. Além da capacidade de testar acima e abaixo dos seus limites para demonstrar que a sua calibração está funcionando.

Não existe um único melhor. As regras são desenhadas com base no risco, por isso o sistema certo depende do que você vende, para quem vende, onde opera e quanto volume processa. O que serve para um emissor de moeda eletrônica em um único mercado não se estende a um negócio de pagamentos multi-jurisdicional, e o que um banco global usa soterraria uma plataforma de trading menor.

O que os bons sistemas têm em comum:

• Detecção alinhada às suas tipologias, e não a um modelo genérico
• Alertas explicáveis, para que o seu analista consiga dizer por que um alerta foi disparado e o seu investigador consiga redigir algo que resista a escrutínio
• Ajustes demonstráveis, incluindo dados de precisão de alertas e um método documentado para alterar limites
• Uma trilha de auditoria que você possa reproduzir meses depois: a regra, os dados, o revisor, a justificativa, as aprovações
• O timing certo para cada controle. O screening de sanções ocorre antes que um pagamento saia. O monitoramento comportamental normalmente roda em batch ou quase em tempo real, porque os padrões relevantes se formam ao longo de dias e entre várias contas. A decisão em tempo real tem o seu lugar quando você precisa reter fundos antes da liquidação em rails instantâneos, mas isso é uma decisão comercial e de apetite de risco. O que os reguladores exigem é reporte rápido assim que a suspeita se forma.
• Relatórios adequados a cada mercado em que você reporta. Os prazos variam muito. Alguns regimes exigem um relatório em até um dia após a formação da suspeita e limitam quanto tempo a revisão interna que leva a isso pode durar. Outros permitem um mês ou mais a partir do ponto de detecção. Alguns supervisores adicionam uma janela esperada do alerta ao envio além da obrigação legal de reportar sem demora. Uma única configuração global padrão vai violar os requisitos mais rígidos.

Avalie fornecedores segundo os seguintes critérios:

• Cobertura e configurabilidade. Quais tipologias a solução cobre para o seu setor e os seus mercados? Procure uma biblioteca de cenários da qual você possa partir e depois ajustar à sua própria avaliação de risco.
• Explicabilidade e supervisão humana. Um analista consegue ver por que um alerta foi disparado? Quando houver machine learning envolvido, o resultado pode ser explicado a um regulador? O sistema prioriza o trabalho. Pessoas reais tomam a decisão.
• Qualidade dos alertas. Peça dados de precisão, não números de throughput. A sua verdadeira restrição é o volume de alertas em relação à capacidade dos analistas, não a quantidade de transações processadas.
• Testes antes do go-live. Você consegue fazer backtest de novos cenários com dados históricos e simular o volume de alertas que uma mudança de limite produziria? É isso que torna o ajuste algo comprovável.
• O que o sistema sabe sobre os seus clientes. O monitoramento funciona muito melhor quando se apoia nos seus dados de onboarding e risco do cliente, para que a atividade seja julgada com base no que você já sabe, e não de forma isolada.
• Operação multi-mercado. Workflows e prazos de reporte configuráveis por mercado, suporte a formatos e portais locais, tratamento de idiomas locais e diferentes conjuntos de regras para diferentes entidades sem operar sistemas separados.
• Residência e retenção de dados. Onde os dados são processados e armazenados, e isso atende aos requisitos locais de proteção e localização de dados em cada mercado? A linha de base do FATF é de cinco anos para registros de transações e clientes, e várias jurisdições exigem mais, portanto a retenção precisa ser configurável, e não fixa.
• Controles pré-transação descritos com precisão. Controles em tempo real podem reter ou recusar um pagamento. Eles não podem impedir a suspeita, que é uma avaliação humana. Quando você retém um pagamento por motivos de lavagem de dinheiro, a lei local decide o que acontece depois, e em várias jurisdições você precisa de autorização antes de prosseguir. As restrições sobre o que pode dizer ao cliente se aplicam durante todo o processo. A ferramenta deve apoiar esse workflow, não alegar eliminá-lo.
• Entrar em produção. Prazos de implementação, migração do sistema atual e se você consegue operar ambos em paralelo por tempo suficiente para comparar resultados antes de fazer a troca.
• O próprio fornecedor. Viabilidade, modelo de suporte, níveis de serviço e para onde o produto está indo. Você está comprando uma relação que precisa sobreviver às suas próximas auditorias, não apenas um software.