Regras de monitoramento de transações que identificam riscos em vez de ruídos.

Charles Archibong, Cofundador
Uma regra de monitoramento justifica sua existência quando corresponde a um risco real, é acionada por dados reais enviados e gera alertas que um analista pode encerrar com uma justificativa. Ajuste as regras com base em resultados específicos, nunca apenas na contagem de alertas.

Pontos principais
- Cada regra deve estar relacionada a um risco específico em sua própria avaliação de riscos; caso contrário, trata-se de ruído intencional.
- As regras comportamentais permanecem silenciosas sem os campos que leem, como direção, contraparte e canal.
- Os limites por moeda e as linhas de base por cliente são mais vantajosos do que um limite global único para carteiras mistas.
- Ajuste uma regra pelos seus rótulos de verdadeiros e falsos positivos, e não pela quantidade de alertas que ela gera.
Uma regra de monitoramento de transações justifica sua existência quando cumpre três requisitos: ela se relaciona a um risco real que você corre, é acionada por dados que você realmente envia e gera alertas que um analista pode encerrar com uma justificativa clara. Uma regra que falha em qualquer um desses testes apenas aumenta o trabalho sem adicionar detecção.
O ajuste fino decorre do mesmo teste. Avalie uma regra pelo que aconteceu com seus alertas (confirmados, resolvidos, inconclusivos), não pela quantidade que ela gerou. Uma regra que gera 40 alertas por semana e confirma 6 pode ser mais valiosa do que uma que gera 5 e não confirma nenhum.
Por que a maioria dos programas de monitoramento se afoga em alertas?
O volume de alertas geralmente aumenta por razões previsíveis, e a maioria delas são escolhas de configuração, e não atividades criminosas.
Regras copiadas de um modelo, não de uma avaliação de risco. Uma regra para atividades que envolvem grande volume de dinheiro em espécie faz pouco sentido para uma carteira que nunca lida com dinheiro vivo.
Um limite de gastos único para cada cliente. Um limite definido para usuários de varejo assalariados será aplicado o dia todo aos comerciantes, mas nunca a uma conta de estudante usada como "mula".
Regras que leem campos que ninguém envia. Essas regras ou nunca são acionadas, o que gera uma falsa sensação de segurança, ou são acionadas com base em valores padrão que não significam nada.
Alertas duplicados para um mesmo comportamento. Dez pagamentos que violam a mesma regra em um mesmo dia se transformam em dez multas, a menos que as repetições sejam agrupadas.
Cada um desses problemas pode ser resolvido antes mesmo de você tocar em qualquer peso.
Quais regras merecem ser aplicadas ao seu negócio?
Comece pelo produto, não pelo catálogo de regras. A tabela abaixo é um ponto de partida ilustrativo para quatro modelos de negócios comuns. Não se trata de uma lista de verificação regulatória, e sua própria avaliação de riscos deve definir a lista final.
Modelo de negócio | Regras geralmente relevantes para o risco | Regras frequentemente desativadas ou com menor peso |
|---|---|---|
Carteira de particulares ou PSP | Frequência de transações, novo beneficiário, movimento rápido (saídas quase tão rápidas como as entradas), smurfing (vários remetentes para uma conta) | Movimentações em espécie, salvo quando existem depósitos em numerário através de agentes |
Credor de PME | Transferência imediata após o desembolso, novo beneficiário, valores redondos nos reembolsos | Smurfing, raramente adequado a uma carteira de crédito |
Plataforma de câmbio de criptoativos | Listas de contrapartes, geografia, movimento rápido, atividade após inatividade | Valores redondos, pois os montantes em criptoativos raramente o são |
Marketplace | Mudança de perfil (um vendedor inicia um novo tipo de transação), frequência, operações internacionais | Anomalia face à referência nas primeiras semanas de um vendedor |
Duas regras merecem atenção especial porque, embora pareçam complexas, dependem da história.
A regra de anomalia de referência compara um valor com o que é normal para aquele cliente. Um novo cliente não tem histórico, então a comparação precisa recorrer a uma coorte até que haja eventos suficientes. Espere que haja mais ruído nas primeiras semanas de relacionamento.
A regra de inatividade seguida de reativação só faz sentido se a inatividade for incomum na sua carteira. Para um produto de poupança em que meses de inatividade são normais, defina o período de inatividade como longo ou atribua um peso baixo à regra.
Quais dados cada regra precisa para ser acionada?
Este é um erro silencioso comum. As regras comportamentais leem campos específicos, e uma regra com um peso, mas sem os campos correspondentes, nunca é acionada. A fila de alertas parece calma, e essa calmaria não significa nada.
Regra | Dados necessários no evento |
|---|---|
Transferência imediata, movimento rápido |
|
Smurfing |
|
Novo beneficiário |
|
Movimentações em espécie |
|
Operações internacionais | A nacionalidade do cliente e o campo do evento |
Mudança de perfil | Um tipo de transação consistente no campo |
Antes de ajustar qualquer coisa, verifique a cobertura. Em Toden O monitoramento de transações (pontuação em tempo real de transações e eventos do cliente) exibe um painel de cobertura na configuração de regras, sinalizando as regras que estão ponderadas, mas não configuradas. A documentação das regras de monitoramento (abre num novo separador) lista os campos que cada regra integrada lê.
Um exemplo prático: um PSP O sistema envia o valor do pagamento, a moeda e o ID do cliente, mas não a contraparte, porque o sistema de pagamentos armazena os beneficiários em uma tabela separada. Suas regras de exclusão de beneficiários e de novo beneficiário têm peso 0,6 e nunca foram acionadas. A solução é uma alteração na integração, não uma alteração nas regras: adicionar a referência da contraparte a cada evento.
Como devem funcionar os limites de valor em diferentes moedas e tipos de clientes?
Um único limite global tende a produzir falsos positivos e falsos negativos simultaneamente. Dois mecanismos ajudam a solucionar esse problema.
Limites por moeda. Um teto definido em dólares americanos não diz nada de útil sobre uma transferência em naira ou xelim quando a conversão é feita a uma taxa variável. Toden O sistema define limites máximos em uma moeda base com opções de ajuste por moeda, permitindo que um limite de transação única de ₦5.000.000 e um limite de US$5.000 coexistam, cada um aplicado a eventos em sua respectiva moeda. Esses valores são meramente ilustrativos; defina os seus com base nos seus dados de transação.
Linhas de base por cliente. Quando o produto atende a clientes muito diferentes, uma regra de linha de base detecta um aumento anormal para aquela pessoa, mesmo que esteja abaixo de um limite global.
A regra do padrão de estruturação depende do limite de transação única. Toden O sistema procura por uma sequência de três ou mais transações na mesma moeda, entre 70% e 100% do limite, dentro de um determinado período. Se o limite for definido muito acima da atividade normal, a faixa monitorada fica vazia e a regra nunca é acionada. Se for definido muito baixo, clientes comuns se enquadram na faixa. Defina o limite primeiro e, em seguida, avalie a regra de padrão.
Como os pesos e os limites transformam regras em decisões?
Cada regra produz um sinal entre 0 e 1. Toden combina-os por peso em uma pontuação composta usando um OR suave: um sinal forte pode elevar a pontuação por si só, e sinais adicionais a elevam com retornos decrescentes. A pontuação é então comparada com dois pontos de corte.
Pontuação | Decisão |
|---|---|
Abaixo do limite de revisão | ALLOW |
No limite de revisão ou acima dele | REVIEW e um alerta é aberto. |
No limite do bloco ou acima dele | BLOCK |
Essa forma tem uma consequência prática. Os pesos expressam o quanto uma regra deve ser considerada confiável por si só. Uma regra que você nunca usaria sozinha (valores arredondados, por exemplo) deve ter um peso baixo, para que só seja relevante em conjunto com outras. Uma regra que é quase conclusiva (uma contraparte na sua lista de bloqueados) deve ter um peso próximo ao máximo.
Quando as regras predefinidas não descrevem um cenário, uma regra personalizada pode fazê-lo. Uma regra personalizada é uma árvore de condições construída a partir de...all,anyenot, com sua própria pontuação e peso, e é acionado em alertas comocustom:<name>Escolha um nome significativo, pois os investigadores o lerão em todos os alertas e ele aparecerá em... SAR relatórios.
Como ajustar uma regra sem adivinhar?
O ajuste fino exige resultados. Um alerta fechado sem rótulo não ensina nada, portanto, torne o rótulo obrigatório antes do fechamento. Toden Permite que os analistas classifiquem um alerta como verdadeiro positivo, falso positivo ou inconclusivo, e que as execuções repetidas das mesmas regras no mesmo cliente sejam agrupadas em um único alerta, de forma que cada rótulo reflita um comportamento em vez de dez chamados.
Um ciclo de afinação que funciona na prática:
Escolha uma regra de cada vez. Alterar três pesos simultaneamente torna o resultado impossível de atribuir.
Leia os avisos recentes. Conte os alertas confirmados, resolvidos e inconclusivos durante um período suficientemente longo para incluir seu ciclo de negócios normal.
Leia os alertas resolvidos. Dez falsos positivos de uma categoria de comerciante indicam um problema de segmento, não um problema de limite.
Proponha a menor alteração que corrija o padrão. Muitas vezes, trata-se de um limite por moeda ou da exclusão de uma contraparte, e não de uma ponderação menor.
Compare com o histórico antes de salvar. Toden O recurso "Teste de alterações" reproduz eventos recentes com pontuação como um teste somente leitura e mostra quantas decisões seriam alteradas, sem gerar alertas ou cobranças.
Registre o motivo. Anote o que mudou, por que e o que você espera ver. A próxima revisão deve verificar essa expectativa.
Vale a pena mencionar dois antipadrões. Aumentar o limite de revisão para reduzir o volume remove alertas de todas as regras de uma só vez, inclusive daquelas que estavam funcionando. Excluir uma regra por ser ruidosa remove a cobertura de um risco que você já havia identificado; se o risco ainda estiver presente na sua avaliação, corrija a regra.
Uma regra de decisão para cada regra em sua biblioteca.
Antes de uma regra ser mantida, ela deve passar por estas verificações:
Indica o risco que abrange na sua avaliação de riscos.
Os campos que ele lê estão presentes em eventos reais, e você confirmou que ele foi acionado pelo menos uma vez em testes.
Seu peso reflete o quanto você confiaria nele por si só.
Os limites são definidos por moeda, caso seu livro seja multimoeda.
Os alertas são finalizados com uma etiqueta, e alguém revisa essas etiquetas periodicamente.
Cada alteração foi testada à luz de eventos históricos e registrada com uma justificativa.
Uma regra que não consegue passar por essas verificações não está te protegendo. Ela é silenciosa ou ruidosa, e ambas as opções te prejudicam.
Fontes

Charles Archibong
Cofundador
Charles Archibong é cofundador da Toden. Ele escreve sobre verificação de identidade, tecnologia financeira e o trabalho prático de construção de serviços digitais confiáveis.


