Menu Docs
Página inicial do Docs
/ /
/ / /

Detecção de fraude com MongoDB

Essa arquitetura de referência descreve como implementar a detecção de fraudes em tempo real no MongoDB Atlas usando dados de transações operacionais, incorporações vetoriais e modelos dinâmicos de risco.

A arquitetura ingere transações, gera incorporações para capturar padrões comportamentais, recupera eventos históricos semelhantes com o MongoDB Atlas Vector Search e combina pontuações de similaridade com modelos de risco determinísticos para alcançar uma decisão de aprovação, step-up ou recusa. Modelos de risco e listas de observação são armazenados em coleções MongoDB . Os Change Streams do MongoDB propagam atualizações dos serviços de rastreamento em tempo real, para que as decisões de produção sempre usem a lógica mais recente.

Arquitetura de referência de detecção de fraudes
clique para ampliar

figura 1. Arquitetura de referência de detecção de fraudes

  1. Início da transação

    Um canal de pagamento (por exemplo, autorização de cartão, transferência de conta para conta ou carimbo digital) envia uma solicitação de transação para a API de detecção de fraudes. A solicitação inclui identificadores de cliente , dados do fornecedor, metadados de canal, documentos pessoais do dispositivo, informações de IP e atributos básicos da transação, como valor, moeda e data e hora.

  2. Enriquecimento e persistência da transação

    O serviço de detecção de fraudes valida a solicitação e grava um documento de transação em uma coleção de transações no MongoDB Atlas. Cada documento incorpora detalhes do fornecedor, localização GeoJSON, informações do dispositivo e uma estrutura risk_assessment aninhada que armazena pontuações, sinalizadores e diagnósticos.

  3. Geração de incorporação de padrões comportamentais

    O serviço gera uma incorporação vetorial que captura aspectos categóricos e comportamentais da transação, como categoria do fornecedor, canal, impressão digital do dispositivo, faixa de IP, padrões temporais e quaisquer campos numéricos. Ele armazena essa incorporação junto com os campos operacionais no mesmo documento de transação.

  4. Pesquisa vetorial de padrões de fraude semelhantes

    O serviço emite uma query $vectorSearch em relação a um índice do MongoDB Atlas Vector Search na collection de transações. A query usa a incorporação recém-gerada para recuperar transações anteriores com comportamento semelhante, incluindo eventos que não correspondem a regras explícitas, mas compartilham padrões com fraudes conhecidas.

  5. Avaliação do modelo de risco determinístico

    Em paralelo com a pesquisa vetorial na etapa anterior, o mecanismo de risco avalia modelos baseados em regras e no estilo scorecard sobre atributos numéricos e estruturados que permanecem fora da incorporação, como quantidade, alterações de equilíbrio, contadores de velocidade e restrições geoespaciais. Essa separação mantém os limites numéricos e os limites regulatórios na lógica determinística, enquanto as incorporações se concentram na similaridade comportamental.

  6. agregação de pontuação de risco e tomada de decisão

    O serviço combina pontuações de similaridade vetorial com pontuações de risco determinísticas em uma avaliação de risco geral para a transação. Com base em limites e políticas configurados, o mecanismo:

    • Aprova transações de baixo risco e as retorna ao canal de pagamento.

    • Recusa transações de alto risco

    • Emite um desafio step-up (por exemplo, 3-D Secure, OTP ou biométrico) para casos limite e, opcionalmente, encaminha os casos de desafio recusados ou com falha para uma fila de revisão manual para acompanhamento do examinador.

    A decisão final e os diagnósticos de suporte são escritos de volta no subdocumento index_assessment do registro de transações.

  7. Atualizações do modelo de risco em tempo real com Change Streams

    Modelos de risco, listas de observação e documentos de configuração são armazenados em uma coleção risk_models dedicada no MongoDB Atlas. Os MongoDB Change Streams transmitem eventos de alteração, incluindo inserções, atualizações, substituições e exclusões dessas collections para os serviços de detecção de fraudes e mecanismo de risco. Quando os analistas ativam ou ajustam um modelo, todos os mecanismos de triagem recebem a alteração em milésimos de segundo e aplicam regras atualizadas a novas transações, sem atrasos em lote ou invalidação manual de cache. Os tokens de retomada permitem que os serviços reiniciem o processamento sem perder as atualizações após falhas ou reinicializações.

  8. Auditoria, monitoramento e processamento downstream

    O sistema principal de pagamentos processa transações aprovadas, enquanto as transações recusadas ou impossíveis permanecem sinalizadas na collection de transações com diagnósticos de risco detalhados. Os analistas e os trabalhos de monitoramento fazem query na mesma coleção para acompanhar o desempenho do modelo, falsos positivos e padrões de fraude recentes ao longo do tempo.

Use o MongoDB Atlas como a plataforma de dados moderna para detecção de fraudes, hospedando dados operacionais, analíticos e de configuração em um único cluster gerenciado.

O MongoDB Atlas mantém todos os dados necessários para uma decisão de fraude perto da transação, sem extração, transformação e carga (ETL) para armazenamentos secundários para análise ou pesquisas.

abordagem proposta

  • Armazene dados de configuração de cliente, transação e risco usados na tomada de decisões em tempo real.

  • Ofereça suporte a cargas de trabalho secundárias, como análises, painéis e pesquisas sem ETL.

Notas de implementação

  • Comece com um Atlas M10 ou superior para cargas de trabalho de produção ou demonstração em grande escala.

  • Use conjuntos de réplicas (padrão do Atlas ) para ativar o Change Streams e atender a cargas de trabalho de leitura simultâneas.

Crie um esquema de documento que mantenha todos os dados necessários para uma decisão de fraude próximos à transação e, ao mesmo tempo, permita visualizações centralizadas na entidade e na configuração.

abordagem proposta

  • Collection de entidades/clientes

    • Armazene individuais e organizações com um perfil de 360grau: identificadores, atributos Conheça seu Cliente (KYC), análises comportamentais, avaliações de risco e incorporações opcionais para similaridade de entidades.

    • Incorpore ou faça referência a impressão digital de dispositivos, localizações usuais e padrões de comportamento para oferecer suporte a verificações de anomalias como "novo dispositivo" ou "localização incomum".

  • Coleção "transações"

    • Representa cada transação financeira como um documento autônomo com valor, moeda, mercado, localização GeoJSON, informações do dispositivo e um subdocumento risk_assessment incorporado (pontuação, nível, sinalizadores, diagnóstico).

      • Esse padrão permite que o mecanismo de fraude escreva decisões e diagnósticos diretamente no registro de transações que as ferramentas downstream consultam.

  • Modelos de risco/coleção de configurações

    • Armazene modelos de risco versionados como documentos com fatores, pesos, limites e métricas de desempenho. Use esta coleção como a única fonte de configuração para pontuação de fraude.

Para obter informações mais detalhadas, consulte: abordagem do modelo de dados – mitigação de ataques financeiros.

Use o MongoDB Atlas Vector Search para detectar transações que se comportam como padrões de fraude conhecidos ou eventos históricos de alto risco, mesmo quando não correspondem a regras explícitas.

abordagem proposta

  • Armazene incorporações de alta dimensionamento em documentos de transações, capturando sinais comportamentais como categoria do fornecedor, canal, dispositivo, padrão temporal e texto explicativo.

  • Recupere as transações históricas mais semelhantes para cada novo evento usando $vectorSearch e, em seguida, insira pontuações de similaridade no mecanismo de risco.

Notas de implementação

  • Crie um índice de vetor (por exemplo, transaction_vector_index) no vector_embedding campo na transactions coleção.

  • Gere incorporações consistentemente tanto para transações armazenadas quanto para novas transações a bordo que você precisa comparar.

Implemente um serviço de pontuação de fraudes que consome documentos MongoDB e combina contexto de entidade, regras determinísticas e similaridade vetorial em uma única pontuação de risco. Nenhuma estratégia de detecção única captura todas as fraudes. A pontuação em camadas reduz falsos positivos e falsos negativos.

abordagem proposta

  • Carregue o perfil do cliente ou entidade do MongoDB para obter linhas de base e contexto comportamentais.

  • Execute verificações independentes para:

    • Anormalidade de valor em relação aos valores típicos para este cliente.

    • Anormalidade de localização usando a distância geoespacial de locais usuais.

    • Anormalidade do dispositivo com base em dispositivos conhecidos e intervalos IP.

    • Anormalidade de velocidade usando contagens em uma janela de tempo móvel.

    • Semelhança comportamental usando resultados do Vector Search (opcional, dependendo do escopo).

  • Combine as pontuações dos fatores e uma pontuação de risco do cliente de linha de base em uma pontuação de risco 0–100 e mapeie para os níveis low, medium ou high.

Notas de implementação

  • Encapsule essas verificações em um serviço dedicado (por exemplo, FraudDetectionService) em vez de incorporar lógica em drivers, para que você possa reutilizá-la em canais e cargas de trabalho.

Exponha APIs de serviço que envolvem o mecanismo de risco e os padrões de acesso ao MongoDB .

abordagem proposta

  • Fornece uma operação persist-and-score que grava transações e seus documentos risk_assessment no MongoDB (por exemplo, um equivalente a POST /transactions).

  • Forneça uma operação de avaliação sem monitoração de estado que execute o mecanismo de risco sem persistir a transação, o que é útil para simulações ou verificações de pré-autorização.

  • Ofereça endpoints de leitura para procurar transações recentes de alto risco, filtrar por sinalizadores e recuperar históricos no nível do cliente para pesquisas.

Notas de implementação

  • Use OpenAPI ou similar para descrever esses endpoints para que as equipes de canal (móveis, web, bancos principais) possam se integrar de forma consistente.

  • Mantenha as queries do MongoDB (filtros, agregações, $vectorSearch) em abstrações da camada de serviço, não em controladoras.

Use o MongoDB Change Streams e uma collection de configuração dedicada para gerenciar e distribuir alterações no modelo de risco em tempo real.

abordagem proposta

  • Persistir modelos de risco como documentos completos, incluindo definições de fatores, pesos, limites e status (por exemplo, active, draft, archived).

  • Forneça uma API e UI de administração de modelo para que as equipes de risco possam ativar e versionar os modelos sem alterações de código.

  • Use o Change Streams para enviar alterações de modelo para serviços de fraude e UIs por WebSockets ou similar, para que todos os componentes apliquem o mesmo modelo ativo imediatamente.

Integre um provedor de incorporação (por exemplo, AWS Cama) para gerar representações vetoriais para transações e padrões de fraude.

abordagem proposta

  • Gere incorporações a partir do contexto da transação (valor, fornecedor, canal, dispositivo, campos de texto) e armazene-as no MongoDB como parte do esquema de documento .

  • Gere incorporações para descrições ou tipologias de padrões de fraude e armazene-as em uma coleção fraud_patterns, permitindo a pesquisa vetorial baseada em padrões.

Notas de implementação

  • O padrão suporta qualquer fornecedor que retorne incorporações determinísticas e de alta dimensionamento compatíveis com o Atlas Vector Search.

  • Latência versus complexidade do modelo: a geração de incorporação e a pesquisa vetorial adicionam latência ao caminho da decisão. Para canais com orçamentos de latência rigorosos, você pode simplificar incorporações, reduzir a dimensionalidade ou aplicar a correspondência semântica somente a segmentos de alto valor ou alto risco, enquanto executa regras determinísticas puras para tráfego de baixo risco.

  • Tamanho do índicee sobrecarga operacional: índices de vetores de alta dimensionamento e documentos de transações avançados aumentam os requisitos de armazenamento e computação. Planeje o dimensionamento do Atlas cluster, a configuração de índice e as estratégias de arquivamento para equilibrar a qualidade da recuperação, o desempenho do volume de trabalho operacional e o custo. Use índices padrão e índices 2dsphere para queries operacionais e regras geoespaciais e reserva a pesquisa vetorial para cenários em que a similaridade comportamental adiciona valor de detecção claro.

  • complexidade do gerenciamento de configurações: a transmissão de atualizações do modelo de risco por meio de change streams melhora a capacidade de resposta, mas introduz complexidade no gerenciamento e nos testes de configurações. Você deve projetar fluxos de trabalho de promoção, etapas de validação e procedimentos de rollback claros para novos modelos para que as atualizações em tempo real não propaguem regras incorretas para mecanismos de triagem de produção.

  • Limitações de escopo: essa arquitetura se concentra na detecção de fraudes em tempo real para fluxos transacionais. Use padrões separados, mas relacionados, para verificação de identidade, proteção contra a limpeza de ativos (AML) e integração com o KYC e gerenciamento de casos de longa duração, e conecte-os por meio de collections compartilhadas ou pontos de integração em vez de sobrecarregar o pipeline de fraudes com todos os casos de uso de violações de valores.

Para implementar essa arquitetura de ponta a ponta, visite a solução MongoDB Atlas Architecture Center Mitigação de filmes financeiros com o MongoDB Atlas. Use este guia para configurar seu ambiente e siga as instruções passo a passo para implantar um simulador de transações, uma interface web e serviços de suporte para detecção de fraudes e gerenciamento de modelo de risco. A solução também contém recursos adicionais para a mitigação de índices decrimes financeiros.

Voltar

Camada de dados operacionais