Julgue uma transação pela companhia que ela mantém — Somya Rai e MD Sharique, EXL

Ver no idioma original →

Autoria: AI Engineer · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Judge a Transaction by the Company It Keeps — Somya Rai & MD Sharique, EXL · Canal: AI Engineer · 20:21 · Assistir no YouTube

Tópicos: Cibersegurança e segurança de software, Inferência e otimização de modelos, Modelos de IA, Segurança de IA

Resumo

Somya Rai e MD Sharique mostram como uma rede neural de grafos (GNN) pode detectar fraudes que modelos baseados apenas nas características de uma transação não enxergam, ao analisar as conexões entre usuários, comerciantes e transações. A solução combina embeddings gerados pela GNN com XGBoost e melhora a taxa de detecção de fraudes em um orçamento fixo de alertas. A apresentação detalha decisões de amostragem, construção do grafo sem vazamento de dados, agregação de vizinhos e explicabilidade. Por fim, os palestrantes descrevem como otimizaram a inferência para atingir 3,1 ms no P99.

Pontos-chave

• O risco de fraude pode estar nas conexões de uma transação, não apenas nas características da própria linha.
• Transações presenciais e online têm taxas de fraude e padrões de sinal distintos; por isso, são tratadas com modelos separados.
• O objetivo prático é melhorar a precisão entre as transações sinalizadas dentro de um orçamento fixo de alertas.
• A GNN gera embeddings que são fornecidos ao mesmo modelo XGBoost usado como baseline.
• A amostragem preserva o histórico transacional completo dos usuários para não destruir as conexões do grafo.
• Grafos mensais separados e regras temporais ajudam a evitar vazamento entre treino, validação e teste.
• A agregação combina média, máximo e desvio padrão para representar tanto padrões comuns quanto vizinhos potencialmente perigosos.
• A atribuição em subgrafos fornece evidências sobre as conexões que contribuíram para uma pontuação de risco.
• A precomputação de embeddings de usuários e comerciantes reduz o uso de memória e permite inferência em 3,1 ms no P99.

Capítulos

Início	Capítulo	Resumo
00:04	A fraude está nas conexões	Os palestrantes mostram que a mesma transação recebe pontuações muito diferentes quando o modelo considera o contexto de seus vizinhos.
04:11	Resultados e decisões de engenharia	A GNN combinada com XGBoost melhora a detecção, e a apresentação introduz os desafios de amostragem, explicabilidade e latência.
06:14	Amostragem e construção do grafo	A equipe explica como preserva o histórico dos usuários e separa os grafos por mês para evitar vazamento de dados.
10:54	Agregação de vizinhos e resultados	A arquitetura combina estatísticas dos vizinhos e apresenta os ganhos de detecção nos canais presencial e online.
14:02	Explicabilidade para investigações de fraude	A atribuição de subgrafos revela quais conexões influenciam as pontuações e pode apoiar analistas e a depuração do modelo.
16:40	Inferência de baixa latência	A apresentação detalha o serviço em tempo real, a redução de memória com previsões no nível das arestas e a latência final.

Citações

O sinal nunca esteve na linha; estava nas conexões. — 00:35

Quem está conectado a ela e o que essas pessoas estão fazendo agora? — 02:38

Um único vizinho perigoso entre muitos genuínos é exatamente o padrão que os grupos de fraude criam. — 12:29

A evidência no nível das arestas transforma a investigação: em vez de refazer o caso do zero, verificam-se três transações conectadas. — 16:09

Conceitos e entidades

• Somya Rai (pessoa): Vice-presidente de engenharia de IA que apresenta o problema de detecção de fraudes e os resultados do modelo.
• MD Sharique (pessoa): Arquiteto principal de IA que descreve a construção do grafo, a arquitetura e a implantação do sistema.
• EXL (empresa): Empresa associada aos palestrantes e ao sistema de detecção de fraudes apresentado.
• Graph neural network (modelo): Modelo que representa entidades como nós e aprende usando informações dos vizinhos conectados no grafo.
• XGBoost (modelo): Modelo de gradient boosting usado como baseline e também combinado com os embeddings produzidos pela GNN.
• Subgraph attribution (conceito): Método de atribuição que identifica quais conexões em um subgrafo contribuíram para a pontuação do modelo.
• NVIDIA (empresa): Empresa citada como apoiadora da abordagem de previsão no nível das arestas.
• Embeddings (conceito): Representações vetoriais de nós, calculadas pela GNN para uso no modelo de pontuação.

Tradução completa (pt-BR)

00:04 Olá, sou Sam Ray, vice-presidente de engenharia de IA. O que vemos aqui são duas pontuações para a mesma transação, em ambos os casos. À esquerda, uma única compra online, em que analisamos o valor gasto, quem é o estabelecimento comercial, o código MCC, o tipo de dispositivo ou a hora do dia. Ao final da engenharia de atributos, temos 198 atributos, e a pontuação é 0,04, confortavelmente abaixo de qualquer limite que nos levaria a emitir um alerta. Para nós, esta transação parece limpa. À direita, a mesma transação, a mesma

00:35 representação de atributos. Nenhum dado dessa linha mudou. A única coisa que alteramos é o que o modelo pode observar da vizinhança em que ela está inserida. Três das quatro transações — de um usuário, de um estabelecimento comercial e outras duas transações — foram classificadas como fraude na última hora. Agora, a pontuação é 0,91. Portanto, o sinal nunca esteve na linha; estava nas conexões. Assim, fraude não é uma propriedade de uma transação. É uma propriedade da vizinhança em que ela está inserida. Deixe-me descrever a natureza do problema

01:06 porque são dois problemas com o mesmo nome. Uma transação física em um ponto de venda tem uma taxa natural de fraude de aproximadamente 0,05%. Isso é uma em cada 2.000. São sinais bem definidos e com pouco ruído, e a fraude depende, em grande parte, da velocidade das transações do próprio cartão. Já as transações online têm 0,6% de fraude, 12 vezes mais, com maior volume e mais ruído; muito mais do sinal está no estabelecimento comercial e no contexto dos vizinhos. Essas duas carteiras têm taxas-base diferentes e uma geometria de sinais

01:37 diferente. Portanto, na prática, são dois modelos, não um. E aqui está a restrição que faz deste um problema de engenharia, não apenas de modelagem. O orçamento de alertas é fixo. Os analistas revisam as transações com as maiores pontuações, entre 0,5% e 1,5%. Só isso. Portanto, a área sob a curva não é o único objetivo com que nos importamos; importa também a precisão em um K fixo. Para ter valor, um modelo precisa colocar uma fraude real nesse recorte e fazer isso com a

02:07 mesma latência. Então, a pergunta óbvia é: por que não simplesmente criar um modelo HD boost melhor? Fizemos isso para as transações físicas em pontos de venda. Passamos de 40 atributos brutos para 87 atributos criados por engenharia. Após a seleção e as verificações de vazamento, a taxa de verdadeiros positivos passou de 35,5 para 36,6. E, para as transações online, a história é a mesma. Quase 200 atributos criados por engenharia, e ganhamos cerca de um ponto. Então, temos de duas a cinco vezes mais atributos, mas só um ponto a mais de TPR. Agora

02:38 isso não é uma falha de ajuste, certo? É um limite, porque cada atributo que criamos é apenas uma função da mesma linha e do histórico seguro do próprio cartão. Estamos projetando informações que já tínhamos. Atributos tabulares respondem a uma pergunta: como é esta transação? Eles não conseguem responder à segunda: a que ela está conectada e o que essas conexões estão fazendo agora? Compartilhamento de dispositivos, sequências de velocidade entre carrinhos, um estabelecimento comercial que se tornou problemático há 40 minutos. Isso está nas conexões entre as linhas, e um

03:10 modelo que vê uma linha por vez é, por definição, incapaz de enxergar isso, não importa quantas colunas adicionemos. Certo, então este é o modelo mental para o restante da palestra. Uma rede neural de grafos não aprende sobre um nó apenas a partir dos próprios atributos. Aprende a partir da sua vizinhança. Uma camada, três operações. Primeiro, reunir. Trazemos os estados ocultos de cada vizinho por meio das arestas de ligação, como transação para usuário e transação para estabelecimento comercial, e os agregamos. Reduzimos esse conjunto de vizinhos, que tem um tamanho diferente para cada nó, a um vetor de largura fixa, e fazemos isso com uma função invariante à permutação. A função que escolhemos importou muito mais do que esperávamos, e Sharique vai voltar a esse ponto. Terceiro, atualizar. Combinamos essa agregação com o estado do próprio nó, passamos o resultado por camadas aprendidas e então empilhamos duas camadas. Assim, cada transação conhece seus vizinhos e os vizinhos deles antes mesmo de o classificador vê-la. Então, esses resultados funcionam? Sim, funciona,

03:41 sim. E quero ser preciso sobre o que está sendo comparado. Não substituímos o XGBoost. Alimentamos o XGBoost. A GNN produz os embeddings. Esses embeddings são fornecidos ao mesmo modelo de boosting de gradiente, e é isso que gera a pontuação. Portanto, a comparação é entre o XGBoost sozinho e o XGBoost mais a GNN. Os três números que gostaríamos de destacar primeiro são: aumento relativo de 27% a 33% na taxa de verdadeiros positivos em relação a uma linha de base tabular, usando a mesma taxa de alertas, o mesmo período de avaliação e os mesmos

04:11 atributos disponíveis para ambos os modelos. Segundo, aproximadamente US$ 65 milhões em captura incremental projetada de fraudes, anualizada, somando as duas carteiras de cartões. Terceiro, P99 de 3 milissegundos em inferência. Então, esta palestra não é apenas sobre os números; é sobre como chegamos até aqui. Quatro decisões, e a ordem importa. Primeiro, a amostragem: a fraude ocorre em uma a cada 2.000 transações. Portanto, não podemos treinar com a distribuição bruta. Precisamos elevar a

04:43 taxa de fraude, mas este não é um conjunto de dados tabular em que as linhas são independentes. Cada exemplo negativo que removemos leva consigo suas conexões. Fazer subamostragem do jeito mais simples mantém os rótulos, mas elimina a vizinhança que dá valor a eles. A chave foi manter uma taxa de fraude-alvo moderada sem realmente romper a conectividade. Segundo, a criação do grafo e dos atributos, com o estado contra vazamento — o que é mais difícil do que parece quando as arestas carregam registros de data e hora, além de 32 atributos derivados criados para detectar

05:13 fraudes. Terceiro, explicabilidade: analistas não agem com base apenas em um número. Este é um trabalho regulamentado, em que a pontuação precisa vir acompanhada de evidências; caso contrário, não é lançado. E há a inferência em 3 milissegundos. Duas coisas nos levaram até aqui: o método de agregação e a mudança da previsão no nível do nó para o nível da aresta. Por fim, uma iteração que validamos após o lançamento foi criar e treinar o modelo com uma janela móvel, além de uma abordagem DK baseada em arestas temporais, e isso melhorou os números novamente.

05:43 Com isso, gostaria de passar a palavra a Shahi para explicar os detalhes de como criamos os grafos, como os otimizamos e quais decisões de engenharia tomamos para otimizar ainda mais esse modelo. >> Olá, sou Mohammed Sarik, arquiteto principal de IA. Esta é a palestra “Judge a Transaction by the Company It Keeps”. Como uma rede neural de grafos superou o XGBoost em mais de 30% na captura de fraudes e como a servimos em 3 milissegundos. Vou percorrer a implementação técnica, a amostragem, a construção do grafo, a

06:14 inferência e a explicabilidade. Vamos começar. A primeira decisão que a maioria das equipes erra é a amostragem dos dados. Mantemos uma taxa de fraude-alvo moderada de 0,5% para transações com cartão associadas a estabelecimentos comerciais, cerca de 10 vezes a taxa natural de fraude de 0,05%, e de 6% para transações online, também cerca de 10 vezes a taxa natural de fraude de 0,6%. Ambas são bem mais moderadas

06:45 do que a superamostragem ou subamostragem agressiva que um pipeline tabular usaria. Por quê? Porque todo o histórico transacional de cada usuário selecionado permanece no grafo. Se você cortar o histórico de um usuário legítimo para atingir uma proporção entre classes, rompe a conectividade da qual dependem os vizinhos dele. E as próprias transações legítimas de um usuário fraudulento também são mantidas, como exemplos negativos difíceis, os mais úteis para a fronteira de decisão. Se houver necessidade de aplicar um limite, apenas o orçamento de palavras dos usuários legítimos

07:16 é reduzido. Os usuários fraudulentos nunca são limitados. O desequilíbrio entre classes é tratado depois, com amostragem balanceada de lotes dentro do treinador. Aqui está a comprovação: o grau médio dos usuários no treinamento é de 11,5 a quase 14 para transações com cartão associadas a estabelecimentos comerciais, o que corresponde ao que o modelo vê na inferência. Se a vizinhança durante o treinamento não corresponder à vizinhança durante a inferência, o modelo aprende a coisa errada. Isso se mantém estável ao longo dos 12 meses

07:47 que testamos, nas taxas naturais de 0,05% e 0,6%. Não há deriva de distribuição para corrigir. Segunda decisão: controle de vazamento incorporado ao próprio grafo, em vez de verificado depois. Cada mês-calendário é um grafo separado, sem arestas que cruzem os limites. A transação é o nó central, com arestas para o usuário e o estabelecimento comercial. Além disso, há uma cadeia de cinco saltos

08:19 que volta ao histórico recente do próprio nó. Como os meses nunca se conectam, não há caminho para que informações vazem de uma divisão para outra. Dessa construção resultam quatro propriedades. Sem vazamento de informações futuras: uma transação só agrega vizinhos com um registro de data e hora anterior. Sem vazamento entre treino, validação e teste, devido à separação dos meses. Sem vazamento de rótulos. O indicador de fraude é o alvo, nunca um

08:50 segue a cadeia de volta até seu próprio histórico recente. Como os meses nunca se conectam, não há caminho para que informações vazem de uma divisão para outra. Quatro propriedades decorrem dessa construção. Sem vazamento do futuro. Uma transação só agrega vizinhos com um registro de data e hora anterior. Sem vazamento entre treino, validação e teste, porque os meses são disjuntos. Sem vazamento de rótulos. O indicador de fraude é o alvo, nunca uma

09:20 característica ou vantagem. E nenhum vazamento de distribuição. Cada escalar e vocabulário é ajustado apenas com o mês de treinamento e, depois, congelado. Quatro em quatro, verificados por construção, não por auditoria post hoc. Mais uma decisão antes da arquitetura. 202 características do modelo em três tipos de nós: 73 no usuário, 109 na transação e 20 no estabelecimento. 32

09:51 das características transacionais são derivadas. Criadas especificamente para detectar fraude e adicionadas em três etapas. Dez características de histórico da entidade: contagem de transações anteriores, dias desde a última atividade, a média, o desvio padrão e o valor máximo dos cinco últimos valores, uma referência comportamental por usuário e estabelecimento. Oito agregados de risco: uma pontuação do valor em relação a esse histórico, uma proporção entre o recente e o passado, transações por dia.

10:24 Essas características sinalizam desvios em relação à própria referência da entidade, não em relação a algum limite global. E 14 características reais de velocidade em janela móvel e temporais: contagens e valores de transações em 5 minutos, 1 hora e 24 horas. Contrapartes distintas no último dia, segundos desde a última transação, até mesmo uma taxa de mudança de país para identificar padrões de deslocamento impossíveis. Por que isso importa? O grafo informa ao

10:54 modelo a que transações uma transação está conectada. Essas características derivadas informam como essa entidade está se comportando de maneira diferente do seu padrão normal: sinais complementares, não redundantes. Por baixo dos panos, a arquitetura é GraphSAGE: amostrar, agregar e combinar embeddings, amostrando um conjunto fixo de vizinhos por salto, com viés de recência. Assim, um enorme nó de estabelecimento não consegue dominar todas as

11:26 mensagens. Agregamos. E aqui há um detalhe que vale a pena destacar. Não calculamos apenas a média. Concatenamos três estatísticas invariantes à ordem: média, máximo e desvio padrão. Combinamos isso com o próprio vetor do nó usando pesos aprendidos. O resultado é um vetor de tamanho fixo por salto. É indutivo. Aprendemos os pesos do agregador, não um vetor fixo por nó. Assim, um usuário ou estabelecimento totalmente novo recebe um embedding na hora. Sem

11:59 retreinamento. Por que usar três estatísticas em vez de uma? Vou mostrar. Imagine quatro vizinhos de uma transação. Três parecem completamente normais, com pontuações em torno de 0,1. O quarto está ligado a uma rede de fraude. 0,92. Calcule a média desses quatro e você obtém 0,32. O vizinho ligado à rede acabou diluído no conjunto.

12:29 Em vez disso, use o máximo, e ele aparece sem ser diluído: 0,92. Por isso, não confiamos apenas na média. Um único vizinho perigoso entre muitos legítimos é exatamente o padrão criado pelas redes de fraude. E o agrupamento pela média é justamente a operação que o ocultaria. O desvio padrão acrescenta uma terceira perspectiva: o quanto os vizinhos diferem entre si. Uma vizinhança uniforme e sem nada de especial não se parece em nada com outra que tenha

13:00 um outlier ativo. E isso não nos custou nada a mais no momento de atender às solicitações. Nenhum parâmetro aprendido adicional. A saída continua tendo tamanho fixo, independentemente de quantos vizinhos um nó tenha. Uma observação rápida sobre hiperparâmetros: 128 dimensões é o ponto ideal. 64 dimensões fica perto, mas apresenta um leve underfitting. 256 custa mais GPU e não traz

13:31 nenhum ganho. O desempenho na validação se estabiliza acima de 128 e depois começa a apresentar overfitting. Não é um debate filosófico, apenas uma busca de hiperparâmetros. Agora, os números reais lado a lado. Para transações com estabelecimentos em compras presenciais com cartão, o melhor XGBoost atinge uma taxa de verdadeiros positivos de 36% com uma taxa de alerta fixa de 0,5%. GNN mais XGBoost chega a 48%.

14:02 Um aumento relativo de 33%, com US$ 5,66 milhões capturados a uma taxa de captura de 83%. Para transações online, sobe de 48% para 61%. Aumento relativo de 27%, com US$ 35,4 milhões capturados a 71%. É nas transações online que se concentra a maior parte dessa economia de US$ 65 milhões, já que elas têm uma taxa de fraude 12 vezes maior do que as transações com estabelecimentos em compras presenciais com cartão.

14:35 Terceira decisão: explicabilidade. Executamos atribuição de subgrafos em 200 casos sinalizados de cada canal. As arestas de velocidade entre transações têm importância média de 0,94 nas transações com estabelecimentos em compras presenciais com cartão e de 0,62 nas transações online; elas são a principal evidência em todos os 200 casos de compras presenciais com cartão.

15:07 As arestas de estabelecimentos importam mais nas transações online: 0,19 contra 0,04 nas compras presenciais com cartão, em que a fraude se manifesta na própria velocidade do cartão, e não no ponto de aceitação. Essa é a diferença entre o modelo dizer “91” e o modelo dizer “91 por causa destas três transações conectadas nos últimos 40 minutos”.

15:38 Por que isso importa tanto especificamente em fraude? Por quatro motivos. Primeiro, regulamentação e gestão de risco de modelos. As instituições financeiras operam sob estruturas que exigem uma justificativa documentada para decisões automatizadas. Isso não é opcional. Segundo, confiança dos analistas e rapidez das investigações: uma pontuação alta sem explicação é aprovada sem questionamento ou ignorada. Evidências no nível das arestas

16:09 transformam a reconstrução do caso do zero em algo verificável: três transações conectadas. Terceiro, depuração do modelo: os padrões de atribuição nos mostram quando o modelo se apoia em um sinal espúrio ou em declínio, antes que o desempenho caia visivelmente em produção. E quarto, qualidade do ciclo de feedback. Quando a explicação corresponde ao que o analista já suspeita, ele confia o bastante nas decisões limítrofes para rotulá-las corretamente, melhorando a próxima rodada de

16:40 dados de treinamento. Uma caixa-preta precisa simplesmente não é usada. Agora, o verdadeiro desafio é atender a essas soluções em 3 milissegundos. Offline, fazemos o cálculo em lotes, limitado pela memória, com uma passagem direta do GraphSAGE por camadas, fragmentada por nó de destino. Assim, ela é numericamente idêntica a uma passagem direta pelo grafo inteiro, mas limitada a alguns gigabytes por vez, em várias GPUs. Cada

17:13 usuário, estabelecimento e transação recente recebe sua representação por camada em um armazenamento de embeddings em cache de baixa latência. As cinco últimas transações de cada usuário ficam online em um buffer circular. No momento da solicitação, uma etapa leve de montagem reconstrói os estados dos vizinhos diretamente a partir desse cache. Sem reconstruir o grafo, sem amostragem. A ponderação por recência usa uma decadência exponencial que reproduz

17:44 exatamente o treinamento. Depois, o serviço de pontuação em tempo real executa apenas a passagem direta de duas camadas da nova transação, usando esses estados em cache, além da camada do XGBoost. Nada que escale com o tamanho do grafo é executado a cada solicitação. Três pequenos truques tornam isso rápido na prática. Fixamos em um o número de threads da biblioteca matemática antes mesmo de carregar as bibliotecas pesadas. Isso, por si só, é a

18:14 diferença entre 30 milissegundos e 1. Aquecemos o modelo na inicialização para que a primeira solicitação real não seja lenta. E, hoje, tudo roda em um único processo na memória. A mesma interface pode ser conectada diretamente a um cache distribuído quando precisarmos escalar horizontalmente. Mas há um porém. Esse truque exige armazenar em cache uma representação para cada nó, incluindo cada transação, em escala de produção. São 60 GB, e isso

18:47 exige um serviço caro com muita memória e um atraso de um dia nos embeddings em tempo real. A taxa de verdadeiros positivos cai, na verdade, de 48% para 44%. A solução é fazer previsões nas arestas, não nos nós. Pré-calculamos embeddings apenas para usuários e estabelecimentos, nunca para cada transação. Isso reduz o espaço ocupado para dois a três gigabytes, cerca de 20 vezes menos, barato o suficiente para rodar na mesma classe de CPU

19:17 do modelo XGBoost que fica ao lado. A Nvidia recomendou a mesma abordagem de forma independente e espera que seu desempenho seja equivalente ao do modelo por nó. Aqui está o caminho real da solicitação. O pré-processamento, a consulta ao cache e a camada do XGBoost levam, cada um, frações de milissegundo. A passagem direta real de duas camadas da GNN é a maior etapa individual, com 1,61 milissegundo. De ponta a ponta, são 2,3 milissegundos

19:50 na mediana e 3,1 no P99, confortavelmente dentro do nosso SLA de 3 a 4 milissegundos. Se algum dia precisarmos de mais margem, a passagem direta da GNN será a primeira coisa que recompilaremos ou quantizaremos. [música] Obrigado por assistir. Nós dois estamos à disposição para aprofundar a amostragem, a construção do grafo,

20:21 a explicabilidade ou o atendimento das solicitações. Entre em contato a qualquer momento. Obrigado.

Transcrição original

[00:04] Hi, I’m Sam Ray, VP of AI engineering. What we see here are two score, same transaction both the times. On the left, a single online purchase where we look at the amount spent, who is the merchant, MCC code, device type or time of the day and with 198 features by the time we are done engineering and it scores 0.04. comfortably under any threshold we would alert on. As far as we are concerned, this one looks clean on the right. Same transaction, same

[00:35] feature vector. Not one bite of that row is different. The only thing that we change is what model is allowed to look at the neighborhood it sits in. Three of the four transactions, a user, a merchant, and two other transactions were flat fraud within the last hour. Now the score is 0.91. So the signal was never in the row, it was in the edges. Therefore, fraud isn’t a property of a transaction. It is a property of the neighborhood it sits in. Let me describe the shape of the problem

[01:06] because it is two problems wearing one name. Physical transaction at a merchant point of sale roughly has 0.05% natural fraud rate. That is one in 2,000. These are tight low noise signal and fraud largely resigns the card’s own transaction velocity. Whereas online transactions have 0.6% of the fraud 12 times higher with higher volume noisier and far more of it of the signal sits in the merchant and the neighbor context. These two portfolios have a different base rate and a different signal

[01:37] geometry. Therefore in practice two models not one. And here is the constraint that makes this as an engineering problem not and not just the modeling one. The alert budget is fixed. Analysts review the top 0.5 to 1.5% of the score transaction. That’s it. So the area under the curve isn’t just the objective we care about, rather the precision at a fixed K. To be worth anything, a model has to move a real fraud into that slice and do it at the

[02:07] same latency. So the obvious question here is why not just build a better HD boost model. We did physical point of sale. We went from the 40 raw attributes to 87 engineered features. After selection and the leakage checks, the two positive rates moves from 35.5 to 36.6. And for the online transaction, same story. Nearly 200 engineered features and we pick up about a point. So you know two to five times the feature surface one point of DPR. Now

[02:38] that’s not a tuning failure, right? That’s ceiling because every feature we engineered is just a function of the same row and the safe card’s own history. We are projecting the information we already had. Tableau features answers one question. What does this transaction look like? They cannot answer the second one. Who is it connected to and what are they doing right now? Range sharing a device velocity chains across cart. A merchant went that went bad 40 minutes ago. This lives in edges between the rows and a

[03:10] model that sees one row at a time is blind to it by design. No matter how many columns we add to it. Okay, so here’s the metal model for the rest of the talk. A graph neural network does not learn a node from its own feature. It learns from its its neighborhood. One layer, three operations. First, gather. We pull in each neighbor’s hidden states across the tie edges such as transaction to user, transaction to merchant aggregate. We collapse that neighbor set which is you

[03:41] know a different size for every node one into a fixed width vector and we do it with a permutation in function. Which function we picked mattered way more than we expected and charik is going to come back to that. Third update. We concentrate that aggregate with the node’s own state, push it through learns and then we stack it twice. So every transaction knows about its neighbors and its neighbors neighbor before the classifiers ever sees it. So does these results work up? Yes, it

[04:11] does. And I want to be precise about what’s being compared. We did not replace XG post. We fed it. The genet produces the embeddings. these embedding scores into the same gradient boosted model and that’s what can score. So XG boost alone versus XG boost plus the curve is what we are comparing at. So the three numbers that we would like to highlight first is 27 to 30% 33% related lift in the true positive rate over a two leg baseline using the same alert rate same evaluation window and same

[04:43] features available to both the models. Second, approximately $65 million projected annualized incremental fraud capture across the two cardboard or third the 3 millisecond P99 in barash. So this talk is just not about the numbers, it’s about how we got here four decisions and order matters. First and the foremost sampling fraud is 1 in 2,000. So we cannot train a raw distribution. We have to lift the

[05:13] thought rate but this is not a tablet data set where the rows are independent. Every negative we drop takes its edges with it. Down sample the easy way we keep the labels but lose the neighborhood that makes them worth anything. So holding a soft target fraud rate without really breaking the connectivity was the key. Second, graphing features building at leakage state which is harder than it sounds when your edges carry time stamps plus 32 derived features created to detect

[05:43] fraud. The third explanability analyst won’t action a number. This is a regulated work where the score has to come with an evidence so or it does not ship and serving at 3 milliseconds. Two thing got us here. The aggregation method and the pivot from the node level prediction to edge level. Then at the end one iteration that we validated after launch was creating and training the training the model at a rolling window plus an edge himed DK approach and this move the numbers again

[06:14] with this I would like to hand it over to Shahi to get into the nuts and bolts of how did we create the graphs how did we optimize the same and what were the engineering decisions that we have taken in order to make this model more optimized. >> Hi I am Mohammed Sarik principal AI architect. This is judge a transaction by the company it gives. How a graph neural network bid exib boost by over 30% on fraud capture and how we serve it in 3 milliseconds. I will walk through the technical build, sampling, graph

[06:45] construction, serving and explanability. So let’s get into it. First decision most teams get wrong is the data sampling. We hold a soft target fraud rate of.5% for card related merchant transactions about 10 times the 0.05% natural fraud rate and 6% for online transactions again about 10 times the 0.6% natural fraud rate. Both far gentle

[07:16] than the aggressive over or under sampling a tabular pipeline would use. Why? Because every selected user’s complete transactional history stays in the graph. If you trim a genuine user’s history to hit a class ratio, you break the connectivity their neighbors depend on. And a fraud user’s own genuine transactions stay in two. As hard negatives, the most useful example for the decision boundary. If capping ever triggers, only the genuine users word

[07:47] budget shrinks. Fraud users are never capped. Class imbalance gets handled downstream instead with balanced batch sampling inside the trainer. Here’s the receipt. Average user degree at training time 11 and a half to almost 14 for card related merchant transactions matches what the model sees at inference. If training time neighborhood don’t match inference time neighborhood, the model learns the wrong thing. It’s stable across all 12 months

[08:19] we tested at natural rate of 0.05% and 0.6%. No windage drift to correct for second decision leakage control built into the graph itself not checked for afterward. Each calendar month is its own disjoint graph. No edge overcrosses the boundary. The transaction is the central node with types out to its user and its merchant. Plus a five hop

[08:50] follows chain back to its own recent history. Because months never connect, there’s no path for information to leak from one split into another. Four properties fall out of that construction. No future leakage. A transaction only ever aggregates neighbors with an earlier time stamp. No train val test leakage because of the disjointed month. No label leakage. The fraud flag is the target, never a

[09:20] feature or an edge. And no distribution leakage. Every scalar and vocabulary is fit on training month only then frozen. Four for four verified by construction not by post hawk audit. One more decision before the architecture. 202 model features across three node types. 73 on the user, 109 on the transaction, 20 on the merchant. 32

[09:51] of the transactional features are derived. Purpose-built for fraud added in three waves. 10 entity history features. Past transaction count, days since last activity, the mean standard deviation and max of the last five amounts, a behavioral baseline per user and merchant. Eight risk aggregates, an amount jet score against that history, a recent versus past ratio, transactions per day.

[10:24] These flag deviation from the entity’s own baseline, not some global threshold. and 14 true rolling window velocity and temporal features. 5 minute, 1 hour, and 24hour transactional counts and amounts. Distinct counterparties in the last day, seconds since the last transaction, even a country change rate for impossible travel patterns. Why this matters? The graph tells the

[10:54] model who a transaction is connected to. These derived features tell it how that entity is behaving differently from its own normal complimentary signals not redundant ones under the hood. This is graph says architecture sample aggregate combine embed sampling a fixed recency bias set of neighbors per hop. So, one enormous merchant node can’t dominate every

[11:26] message. Aggregate. And here’s a detailed worth pausing on. We don’t just average. We concatenate three order invariant statistics. Mean, max, and standard deviation. Combine that with the nodes own vector through learn weights. Embed a fixed length vector to hops. It’s inductive. We learned that the aggregator waits not a fixed vector per node. So a brand new user or merchant gets embedded on the fly. No

[11:59] retraining. Why three statistics instead of one? Let me show you. Picture four neighbors of a transaction. Three look completely normal. Scores around 0.1. The fourth is tied to a fraud ring. 0.92. Average those four together and you get 0.32. That ring linked neighbor just got diluted into the crowd.

[12:29] Take the max instead and it comes through untouched. 0.92. That’s why we don’t rely on mean alone. A single dangerous neighbor among many genuine ones is exactly the pattern fraud rings create. and mean pooling is precisely the operation that would hide it. The standard deviation adds a third view. How much the neighbor disagree with itself. A uniform boring neighborhood looks nothing like one with

[13:00] a live outlier in it. And this cost us nothing extra at serving time. No additional learned parameters. still a fixed size output no matter how many neighbors a node has one quick hyperparameter note 128 dimension is the sweet spot 64 dimension is close but slightly under fit 256 cost more GPU and gives you

[13:31] nothing back validation performance flattens past 128 and then starts to overfeit It’s not a philosophical debate, just a sweep. Now the actual numbers side by side. For card related merchant transactions, best Exib Boost gets 36% true positive rate at a fixed 0.5% alert rate. GNN plus Exiboost gets 48%.

[14:02] A 33% relative lift, $5.6 6 million captured at an 83% capture rate. For online transactions, 48% up to 61%. 27% relative lift, $35.4 million captured at 71%. Online transaction is where most of that $65 million savings lives since it runs at 12 times the fraud rate of card

[14:35] related merchant transactions. Third decision explanability. We ran subgraph attribution across 200 flag cases in each channel. Transaction totaction velocity edges carry 0.94 mean importance in card related transactions 0.62 in online transactions and they are the top piece of evidence in all 200 card present cases.

[15:07] Merchant edges matter more in online transactions 0.19 versus 0.04 04 in card present where fraud writes the card’s own velocity rather than the acceptance point. That’s the difference between the model says 91 and the model says 91 because of these three linked transaction in the last 40 minutes.

[15:38] Why does this matter so much specifically in fraud? Four reasons. One, regulatory and model risk management. Financial institutions operate under frameworks that require documented rational for automated decision. This isn’t optional. Two, analyst trust and investigation speed and unexplained high score gets rubber stamped or ignored. Edge level evidence

[16:09] turns recomputee the case from scratch into verified three linked transactions. Three, model debugging attribution patterns show us when the model leans on a speurious or decaying signal before performance visibly drops in production. And four, feedback loop quality. When explanation match what an analyst already suspects, they trust the borderline calls enough to label them correctly, improving the next round of

[16:40] training data. An accurate black box simply doesn’t get used. Now the real fight serving these solution in 3 milliseconds. offline van memory bound GPU sarded layer wise graph says forward pass over the entire graph bashed by destination node so it’s numerically identical to a full graph forward just bounded to a few gigabyte at a time across multiple GPUs every

[17:13] user merchant and recent transaction gets its per layer representation cast in a low latency embedding store. Each user’s last five transaction sit in a ring buffer online at request time. A lightweight assembly step reconstructs the neighbor states straight from that cast. No grab build, no sampling. Recense weighted by an exponential decay that reproduces

[17:44] training exactly. Then the realtime scoring services runs only the new transactions own two layer forward from those cache states plus the exeost head. Nothing that scales with graph size runs per request. Three small tricks make it fast in practice. We pin math library thread pulls to one before the heavy libraries even load. That alone is the

[18:14] difference between 30 milliseconds and one. We warm the model up at startup so the first real request isn’t slow. And today it’s a single in-memory process. The same interface maps directly into a distributed cache when we need to scale out. Now there’s a catch. That trick requires caching a representation for every node including every transaction at production scale. That’s 60 GBTE and it

[18:47] needs expensive high memory serving with a one day embedding lag in real time. True positive rate actually drops from 48 to 44%. The fix predict on the edge not the node. premputee embeddings for user and merchants only, never per transaction. That collapses the footprint to two to three gigabytes, about 20 times smaller, cheap enough to run on the same CPU

[19:17] class as the Exib Boost model it sits beside. Nvidia independently recommended the same approach and expects it to perform on par with the node model. Here’s the actual request path. pre-processing, cast lookup, and the exubost head are all fractions of a millisecond. The GNN’s own true two layer forward is the biggest single piece at 1.61 millisecond. End to end 2.3 millisecond

[19:50] at the median, 3.1 at P99, comfortably inside our 3 to 4 millisecond SLA. If we ever need more headroom that GNN forward is the first thing we would recompile or contise. [music] Thank you for watching. We are both happy to go deeper sampling, graph

[20:21] construction, explanability or serving. Reach out anytime. Thank you.