Stripe Radar (fraude em pagamentos)

01 · CONTEXTO

Decidir em uma fração de segundo

Quando alguém clica em comprar, o Radar, solução de prevenção a fraudes da Stripe, entra em ação até a transação ser confirmada. Ele avalia mais de mil características da transação para estimar a probabilidade de fraude, deixa passar as boas e bloqueia as arriscadas ou as desvia para verificações adicionais. É um caso típico de projeto de sistemas de ML com decisão em tempo real: a resposta sai em menos de cem milissegundos.

Dois fatores tornam o problema difícil. A ferramenta precisa ser precisa, rápida e barata por transação, equilibrando o bloqueio de transações ruins contra falsos positivos, isto é, pagamentos bons que são bloqueados. Além disso, a fraude é rara, da ordem de um em cada mil pagamentos. Entre os bilhões de pagamentos legítimos feitos na Stripe, o Radar bloqueia incorretamente apenas 0,1%.

02 · A DECISÃO

Do clique à decisão

Segundo o autor, a equipe se apoia na amplitude da rede da Stripe, descrita como sua maior força, para identificar transações fraudulentas.

1. O comprador confirma a compra e o pedido de pagamento chega à API.

2. Antes de a transação ser confirmada, a API consulta o serviço de pontuação, que avalia as características da transação para estimar a probabilidade de fraude.

3. O desenho inclui as regras personalizadas de permitir ou bloquear que o comerciante cria para ajustar o Radar ao seu negócio.

4. O resultado é uma entre três saídas: deixar a transação passar, bloqueá-la ou desviá-la para verificações adicionais de segurança.

5. No diagrama, o treino do modelo usa o histórico de transações e entrega o modelo ao serviço de pontuação, fora do caminho do pedido de pagamento.

Depois de entender o risco de um pagamento, quem usa o Radar pode melhorar a qualidade dos dados que envia ou criar regras personalizadas de permitir ou bloquear para o seu negócio.

03 · EVOLUÇÃO DO MODELO

De regressão logística a uma rede neural única

A equipe começou com modelos de ML relativamente simples, como a regressão logística, e avançou para modelos mais complexos, como redes neurais profundas, conforme a rede da Stripe cresceu e a tecnologia de ML avançou.

A mudança mais recente descrita no texto veio em meados de 2022: de um ensemble Wide & Deep, composto por um modelo XGBoost e uma rede neural profunda, para um modelo só de rede neural profunda. Segundo a equipe, o XGBoost era incompatível em escala com técnicas de ML mais avançadas que ela queria adotar e reduzia o ritmo de retreino porque não é muito paralelizável.

Simplesmente remover o XGBoost teria causado uma queda de 1,5% no recall, uma regressão considerada inaceitável. Aumentar demais a profundidade da rede arrisca overfitting, em que o modelo memoriza ruído aleatório nas features. A equipe adotou uma arquitetura de rede neural multi-ramo inspirada na ResNeXt.

04 · EXPLICABILIDADE

Explicar importa tanto quanto detectar

Todos os modelos de ML são caixas-pretas até certo ponto, e as redes neurais profundas mais ainda. Por isso é difícil explicar aos usuários por que o Radar pontua as transações como pontua, um trade-off que a equipe aceitou ao escolher redes neurais em vez de técnicas mais simples.

Em 2020 foi criado o risk insights, que mostra ao usuário quais características de uma transação contribuíram para ela ser recusada. Os fatores podem incluir se o nome do titular confere com o e-mail informado e quantos cartões já foram associados a um endereço IP.

1. A pontuação produz o resultado da transação e os fatores que mais pesaram nele.

2. O risk insights mostra ao comerciante quais características da transação contribuíram para a recusa.

3. Com a explicação, o comerciante pode criar regras personalizadas de permitir ou bloquear.

4. Uma visão em tabela das características que mais aumentaram e diminuíram a pontuação serve aos engenheiros para depurar casos de suporte.

Segundo o texto, essa visão em tabela mostra as características que mais contribuíram para aumentar e diminuir a pontuação de fraude, e os engenheiros a usam internamente para depurar casos de suporte.

05 · FEATURES E DADOS

Mais sinais, mais dados

A equipe revisa ataques de fraude passados em detalhe, com relatórios de investigação que tentam entrar na mente dos fraudadores. Nem toda ideia funciona: um indicador booleano sobre o negócio estar sob ataque de fraude distribuído não melhorou o desempenho do modelo tanto quanto o esperado.

Para testar se mais dados bastam, a equipe fez um aumento de dez vezes nos dados de transações de treino e ainda viu melhorias significativas no modelo. O tempo de treino cresce linearmente com o tamanho dos dados, mas a arquitetura só de rede neural, mais rápida de treinar, tornou isso menos problema.