As regras são o ponto de partida de toda equipe de combate a fraudes, e com razão. Elas são rápidas de escrever, intuitivas de entender e respondem diretamente ao que você está vendo.
No entanto, à medida que o seu negócio cresce, o limite deles torna-se rapidamente evidente. Isso cria complexidade operacional e torna a expansão da estratégia muito mais difícil.
Com cada região, método de pagamento, plataforma e segmento de clientes surge um perfil de risco único. As equipes veem esses diferentes perfis de risco e fazem o que sabem: adicionam mais regras, muitas vezes como uma solução rápida para a crescente complexidade. Uma nova regra para pagamentos europeus. Um limite atualizado para dispositivos móveis. Uma nova verificação de velocidade para clientes B2B.
E, por um tempo, isso funciona. Até deixar de funcionar.
Perfis de risco não são a única coisa que muda ao longo dessas dimensões. Os fornecedores relevantes mudam. Os fluxos de autenticação adequados mudam. Os próprios dados disponíveis mudam.
Você pode definir uma regra para diferentes níveis de risco, mas não pode escrever uma regra que diga: "chame este fornecedor de KYB para clientes B2B na Alemanha, acione o 3DS para transações de alto valor vindas de novos dispositivos e ignore o enriquecimento para usuários recorrentes verificados."
É aí que as regras chegam ao seu limite. E é aí que a camada de workflow entra em cena.
Regras de fraude vs. fluxos de trabalho
Deixe-me definir claramente esses dois termos, porque a confusão entre eles é o que causa a maior parte dos problemas que estou prestes a descrever.
Uma regra implementa uma tática. Ela avalia sinais específicos para sinalizar ou bloquear um comportamento específico dentro desse contexto.
Um fluxo de trabalho, por outro lado, implementa sua estratégia de prevenção a fraudes. Ele determina a qual população uma transação ou usuário pertence, quais verificações se aplicam a eles, quais fornecedores são acionados e quais ações estão disponíveis como resultados.
Em resumo, ele cria o contexto operacional para uma melhor segmentação, melhor roteamento e melhores decisões.
Veja como isso funciona na prática:
Uma regra diz: "Marque esta transação se o dispositivo for novo e o IP estiver em um país de alto risco."
Um fluxo de trabalho diz: "Novos usuários que fazem pagamentos acima de US$ 500 passam por uma análise aprimorada: acione o fornecedor de enriquecimento de identidade, execute a inteligência de dispositivo e, em seguida, avalie os sinais de fraude."
O fluxo de trabalho prepara o cenário, e a regra atua nele: nenhuma das duas funciona sozinha.
Um fluxo de trabalho sem regras bem definidas em seu interior é apenas um roteamento sofisticado, com usuários passando pelos caminhos sem realmente tocar em nada.
Uma regra sem contexto de fluxo de trabalho é aplicada a toda a população de forma indiscriminada, detectando fraude em alguns segmentos e gerando ruído em outros.
Se você quiser um passo a passo detalhado sobre como escrever e iterar uma regra de detecção na prática, este artigo apresenta um exemplo real de ponta a ponta.
Regras | Fluxos de trabalho | |
Implementa | Uma tática | Uma estratégia |
Avalia | Sinais presentes no momento do incêndio | População, contexto, necessidades do fornecedor |
Interage com | Sinais e limites | Fornecedores, sistemas de autenticação, ações downstream |
Escopo da alteração | Lógica de detecção (de responsabilidade da equipe de fraude) | Custo, experiência do usuário e postura contra fraudes (multifuncional) |
Os fluxos de trabalho de fraude fazem mais do que apenas encaminhar
Esta é a parte que a maioria das equipes deixa passar, mesmo aquelas que entendem a distinção básica.
Os fluxos de trabalho não apenas categorizam populações e as encaminham por caminhos diferentes. Eles também orquestram o processo ao acionar etapas externas, coletar dados adicionais e continuar a avaliação, tudo isso sem encerrar a sessão.
Quando uma transação chega, um workflow pode acionar um fornecedor de enriquecimento de identidade, aguardar a resposta e então chamar um provedor de inteligência de dispositivo. Depois, com base no que foi aprendido, ele pode decidir se deve disparar um desafio 3DS, invocar uma autenticação biométrica adicional ou seguir diretamente para a avaliação das regras de fraude.
Tudo isso acontece em pleno fluxo, de forma dinâmica, antes que qualquer decisão final seja tomada.
As regras não conseguem fazer isso. Uma regra avalia os sinais que já estão presentes no momento em que é acionada. Ela não busca coletar mais dados, não mantém a sessão aberta e não aciona a autenticação de forma condicional com base no que encontrou.
É isso que torna o fluxo de trabalho a camada de estratégia. Ele decide não apenas quem será verificado, mas como, incluindo quais ferramentas serão acionadas, em que ordem e para qual público.
As regras então realizam a detecção no evento enriquecido e totalmente caracterizado.
Isso também significa que as duas camadas têm superfícies de integração completamente diferentes. As regras interagem com sinais, e os fluxos de trabalho interagem com fornecedores, sistemas de autenticação e ações a jusante.
Confundir fluxos de trabalho e regras (ou tentar fazer tudo passar por um único) é onde a complexidade operacional começa a se multiplicar.
Por que você não pode dar um jeitinho em um para substituir o outro?
Às vezes as equipes até tentam fazer isso. Mas aqui está o que normalmente acontece:
Regras substituindo fluxos de trabalho: Tecnicamente, isso é possível. Você codifica o contexto da população diretamente nas condições das regras:
SE new_user E pagamento > US$500 E região = UE E segmento = consumidor, ENTÃO...
O problema de encadear todas essas regras é que cada uma delas traz o seu próprio contexto. Isso pode funcionar, até você ter três segmentos de clientes, seis regiões e dezesseis métodos de pagamento.
É a explosão combinatória que cria o problema do conjunto de regras inchado.
Mas, mais importante ainda, nada disso resolve o desafio de orquestração de fornecedores. As regras ainda não conseguem chamar um provedor de KYB no meio da sessão, acionar um fluxo 3DS ou manter um evento em aberto enquanto aguardam uma resposta de enriquecimento.
Você conseguiu “hackear” o problema de roteamento, mas deixou o problema de orquestração totalmente sem solução.
Workflows substituindo regras: Isso falha de forma diferente. Teoricamente, você pode criar um ramo de workflow composto por nós sequenciais, cada um contendo uma única lógica de detecção.
Embora isso possa funcionar, torna-se muito difícil de gerenciar rapidamente. As simulações podem ser enganosas, pois as lógicas são executadas de forma sequencial em vez de paralela, o que dificulta perceber sobreposições entre as diferentes “regras”.
Isso também significa que seus fluxos de trabalho ficam incrivelmente sobrecarregados, tornando mais difícil monitorar e orquestrar sua estratégia.
Mas, acima de tudo, isso introduz um grave risco operacional. Sempre que você mexe em uma nova regra ou em uma atualização de versão (o que pode acontecer com frequência), você coloca todo o fluxo de trabalho em risco.
Se você definir um valor errado em uma regra, não estará apenas deixando passar fraudes — poderá também comprometer todo o processo que o seu fluxo de trabalho representa.
Você realmente precisa de fluxos de trabalho para detecção de fraude em tempo real?
Aqui está algo que ouço com frequência: "Somos um processador de pagamentos. Não temos fluxos de onboarding complexos e tudo é em tempo real. Será que realmente precisamos da camada de workflows?"
Sim. Eis o porquê.
É verdade que direcionar eventos em tempo real para diferentes segmentos costuma ser um caso de uso mais simples. Um que você consegue gerenciar apenas com regras, ainda que de forma um tanto desajeitada. Todos nós já vimos isso antes.
Mas o que realmente nos faz falta é a parte de orquestração.
Pense nisso da seguinte forma: quanto mais arriscado for um evento, maior será a minha exposição financeira. E quanto maior for essa exposição, mais disposto estarei a investir em uma decisão mais precisa.
Esse princípio pode se manifestar de diferentes maneiras. Por exemplo:
- Um pagamento acima de US$ 500 seria encaminhado por meio de um pipeline de enriquecimento de dados mais caro.
- Um pagamento com uma pontuação alta do modelo seria encaminhado para um modelo de segunda linha. Um modelo que pode estar desacelerando nosso SLA para uma pequena parte da população, mas que é muito mais preciso.
- Um login em uma conta com saldo alto seria direcionado por um fluxo de 2FA forte.
Como você pode ver, esses casos de uso não tratam de lógica de detecção nem de quais limites aplicar. Eles tratam de por qual pipeline esse evento passaria e a que custo.
Sem uma camada de fluxo de trabalho, você está executando o mesmo pipeline para todos eles. Isso significa que você está ou gastando demais na sua prevenção a fraudes ou deixando de verificar adequadamente seus eventos de maior risco.
Geralmente ambos, em lugares diferentes.
Em tempo real não significa de forma uniforme. A camada de workflow gerencia essa complexidade de população na velocidade que o evento exige, como encaminhar para os fornecedores certos, acionar a autenticação adequada e aplicar o conjunto de regras correto, tudo dentro da mesma sessão.
O instinto de pular fluxos de trabalho em um contexto em tempo real geralmente vem de pensar neles como um conceito de processamento em lote ou de onboarding.
Não são. Elas são o contexto operacional de cada evento, independentemente da velocidade com que esse evento ocorre.
Quem precisa estar na sala para decisões sobre fluxos de trabalho de fraude
Por mais que os fluxos de trabalho sejam projetados para gerenciar a complexidade, eles também introduzem um nível de complexidade na sua organização.
Para explicar isso, vamos primeiro analisar as regras.
Uma nova regra de fraude muda a sua lógica de detecção. A parte interessada é a equipe de fraude: eles identificam um novo padrão de ataque, escrevem uma regra, testam e colocam em produção. Ciclo rápido, escopo bem definido, responsabilidade de ponta a ponta. Eu escrevi sobre todo o processo de lançamento de regras, incluindo backtesting, validação em modo sombra e monitoramento em produção, neste artigo do blog aqui.
Mudanças de fluxo de trabalho são uma conversa diferente, e muitas vezes exigem várias conversas ao mesmo tempo.
Mude quais fornecedores são acionados em um ramo do fluxo de trabalho, e você acabou de tomar uma decisão de custo. As chamadas para fornecedores têm taxas por transação e, em qualquer volume significativo, isso se acumula rapidamente. Essa é uma conversa de operações e finanças.
Mude se um fluxo de trabalho aciona um desafio 3DS ou uma autenticação biométrica adicional para um segmento de clientes, e você terá acabado de mudar a experiência do usuário para essa população. Isso é uma conversa de produto.
Altere a própria lógica de roteamento de quais clientes passam por qual ramificação e você terá mudado sua postura de fraude para esse segmento. Essa é uma decisão da equipe de fraude, mas com implicações de negócio que vão além da própria fraude.
É o seguinte: mudanças no fluxo de trabalho ficam na interseção entre fraude, produto, operações e, às vezes, até finanças. Fazer essas mudanças sem que todas as equipes estejam alinhadas é como alterações bem-intencionadas acabam gerando custos inesperados com fornecedores, atrito com clientes ou lacunas de cobertura — às vezes, as três coisas ao mesmo tempo.
Mas, por outro lado, a complexidade organizacional não é exatamente algo que se possa evitar ao escalar.
Duas camadas, uma stack
As regras levaram todas as equipes de fraude até onde elas estão hoje. Elas não vão desaparecer, nem deveriam. No entanto, as regras, sozinhas, têm um limite.
E esse limite tem menos a ver com a precisão da detecção e mais com a complexidade. No momento em que o seu negócio passa a abranger várias regiões, métodos de pagamento, plataformas ou segmentos de clientes, você passa a operar em um contexto para o qual as regras não foram feitas para dar conta sozinhas.
O roteamento de fornecedores, a orquestração de autenticação, a segmentação da população: tudo isso pertence à camada de fluxo de trabalho. As duas camadas não são rivais. Elas funcionam como uma pilha em que os fluxos de trabalho implementam a estratégia e as regras implementam as táticas. Cada uma faz um trabalho que a outra não consegue fazer.
Regras detectam riscos. Fluxos de trabalho definem a resposta.
Em termos simples, as regras são a forma como as equipes de fraude detectam atividades suspeitas, e os fluxos de trabalho são como elas operacionalizam a resposta. As regras avaliam sinais e limites. Os fluxos de trabalho decidem o que fazer com essas informações, seja escalar para revisão, acionar autenticação, chamar um fornecedor, aprovar ou bloquear. Então, a pergunta que vale a pena fazer à sua equipe não é "devemos usar regras ou fluxos de trabalho?" e sim se a sua camada de fluxos de trabalho realmente reflete a complexidade do seu negócio. E se as regras dentro de cada ramificação estão calibradas para aquela população específica?
Se você ainda está gerenciando variações regionais, segmentação de clientes e roteamento de fornecedores por meio de condições de regras e lógica de exceções, você já chegou ao limite.
Você só pode ainda não ter dado um nome a isso.
