Regras no mesmo dia
O analista escreve a regra, testa com eventos já registrados e publica. O tempo de resposta a um padrão novo é medido pelo padrão, não pelo sprint.
Detecção de fraude
Sinais de dispositivo, checagens de identidade e regras comportamentais em um único fluxo — com os casos na fronteira indo para uma pessoa em vez de virarem chute.
O problema
Um padrão de ataque costuma ficar óbvio poucas horas depois de começar, e a regra que o barra costuma ser simples. O atraso quase nunca está na análise — está na distância entre o analista que achou o padrão e o deploy capaz de agir sobre ele.
O segundo custo é o instrumento sem corte. Quando subir uma regra é caro, os times sobem regras largas demais, e clientes bons são recusados para pegar uns poucos ruins. Mudanças baratas tornam viáveis regras precisas.
Como o fluxo se parece
Numerado porque a ordem é a ordem de execução, não porque é uma lista. Com quantos passos tiver, tudo isso é uma execução só.
Um cadastro, um login, um pagamento, uma troca de dados bancários — o que você quiser pontuar, em um esquema que você define.
Inteligência de dispositivo, checagens de identidade e de documento dos seus provedores, buscadas em paralelo quando não dependem umas das outras.
O que esse cliente, dispositivo ou conta fez antes. Regras de velocidade e de padrão repetido precisam de memória, não só da requisição atual.
Os casos sem ambiguidade — uma parte sancionada, um dispositivo já conhecido como ruim, uma velocidade impossível — param aqui, em vez de consumir capacidade de revisão.
Rode o seu próprio modelo sobre as variáveis montadas acima. O modelo é versionado junto com o fluxo, então todo score é atribuível a um modelo específico e a uma política específica.
Risco baixo passa, risco alto bloqueia, e a faixa do meio vai para uma pessoa — uma ramificação explícita, e não um limiar escondido no código.
O revisor recebe um caso já com os sinais, o score e o motivo do alerta anexados, em vez de um ID de cliente e uma caça ao tesouro.
Liberar, bloquear ou revisar, com a regra que disparou e a versão que a produziu.
O que o fluxo alcança
Um nó de Conexão chama os provedores que você já paga, com as suas credenciais. A ArboRule decide quais chamadas fazer e o que as respostas significam em conjunto — ela não revende o dado nem se coloca entre você e o seu fornecedor.
O que muda
O analista escreve a regra, testa com eventos já registrados e publica. O tempo de resposta a um padrão novo é medido pelo padrão, não pelo sprint.
Quando uma regra custa uma tarde em vez de um release, fica viável escrever a regra estreita que pega o ataque sem pegar os seus clientes.
Os casos chegam com os sinais e o motivo. A revisão é uma decisão de julgamento, não uma investigação sobre o que o sistema estava pensando.
Perguntas
Podem. Um nó de Modelo de ML roda o seu modelo dentro do fluxo, sobre as variáveis que o próprio fluxo montou, e a versão do modelo fica fixada ao lado da versão da política — assim qualquer score é rastreável até o modelo e a lógica exatos que o produziram.
Com uma ramificação explícita. Um nó de Divisão manda a faixa do meio para uma pessoa: um nó de Revisão Manual pausa a decisão até alguém responder, ou um nó de Criar Caso abre um caso para o revisor enquanto o fluxo devolve um encaminhamento. Os dois ficam visíveis no editor, em vez de subentendidos em um limiar.
Podem. Os nós de Ler Entidade consultam o histórico que você registrou de um cliente, dispositivo ou conta — que é justamente do que regras de velocidade, de tentativa repetida e de padrão precisam para funcionar.
Quando você quiser
Monte o fluxo no Sandbox, rode seus próprios casos por ele e leia a trilha antes de qualquer coisa chegar a um cliente.