Agente de IA para Análise de Fraudes em Transações de Vale-Refeição

21 de December de 2025 • Tempo de leitura: 5 min

Como criar um agente de IA que monitora transações de vale-refeição para identificar padrões suspeitos e prevenir fraudes.

1. Propósito e Escopo

Este documento define todos os prompts, configurações de memória, transição entre estados e demais requisitos funcionais para o Fluxo de Agentes "Análise de Fraudes em Transações de Vale-Refeição", uma solução de automação projetada para monitorar transações e identificar padrões suspeitos de fraude. Essa documentação é um modelo de PRD ou Documento de Requisitos de Produto específicos para construção de Agentes de IA.

O objetivo principal é utilizar inteligência artificial para monitorar em tempo real as transações de vale-refeição, detectar anomalias e alertar imediatamente os responsáveis em casos de suspeita de fraude.

2. Contexto e Problema

Problemas Específicos

O agente deve resolver os seguintes problemas:

  • Ocorrência de fraudes em transações de vale-refeição.
  • Dificuldade em identificar padrões suspeitos manualmente.
  • Prejuízos financeiros devido a atividades fraudulentas.

3. Impactos Esperados

A implementação deste fluxo de automação visa alcançar os seguintes resultados:

  • Reduzir as fraudes em transações de vale-refeição em pelo menos 70%.
  • Aumentar a eficiência na detecção de padrões suspeitos.
  • Minimizar os prejuízos financeiros causados por atividades fraudulentas.

4. Visão Geral da Solução

O agente de IA para análise de fraudes em transações de vale-refeição monitora transações em tempo real, aplica regras específicas para identificar fraudes e alerta os responsáveis em caso de suspeita. A seguir são detalhadas todas as regras de negócio e especificações funcionais necessárias para que esse agente atue como um sistema autônomo de detecção de fraudes.

A solução consiste em um fluxo de automação composto por 4 agentes de IA. O processo inicia com a normalização e validação das transações e termina com a geração de alertas para os responsáveis.

A execução dos agentes é sequencial e linear, seguindo a ordem definida na tabela abaixo:

Agentes Função Principal
Agente de Normalização e Validação de Transações de Vale-Refeição (RF 1) Padronizar e validar transações recebidas, saneando campos, normalizando formatos e enriquecendo com atributos derivados para análise de fraude.
Agente de Sinalização de Risco por Regras Determinísticas (RF 2) Aplicar regras de negócio específicas de vale-refeição para identificar fraude evidente e gerar flags e escore de risco por regra.
Agente de Agregação Temporal e Desvio de Padrão (RF 3) Comparar a transação atual com o comportamento histórico resumido para detectar desvios abruptos e padrões repetitivos suspeitos.
Agente de Decisão e Geração de Alerta (RF 4) Consolidar flags e scores, decidir ação operacional e estruturar o alerta a responsáveis de fraude.

5. Protótipos

Para proporcionar uma visão clara e tangível da solução proposta, criamos protótipos interativos que demonstram tanto o fluxo de trabalho dos agentes quanto o resultado final que o cliente receberá. Explore os links abaixo para entender melhor a solução em ação.

6. Requisitos Funcionais

RF 1. Agente de Normalização e Validação de Transações de Vale-Refeição

1.1 Tarefa do Agente

Padronizar e validar transações recebidas, saneando campos, normalizando formatos e enriquecendo com atributos derivados para análise de fraude.

1.2 Prompt ou Instruções do Agente
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo um JSON de uma ou mais transações de vale-refeição. Cada transação contém, no mínimo, os campos: transaction_id, card_id, user_id, merchant_id, merchant_nome, mcc, valor, moeda, data_hora_utc, canal (presencial|online), pos_entry_mode, autorizacao_id, latitude, longitude, uf_merchant (opcional), device_id (opcional), saldo_disponivel (opcional), parametros_config (opcional).

# 2. Objetivo
Padronizar e validar essas transações, saneando campos, normalizando formatos e enriquecendo com atributos derivados para análise de fraude.

# 3. Regras que você deve seguir para gerar sua resposta
- Regra 1 (Campos obrigatórios): Rejeitar a transação se faltar qualquer campo obrigatório: transaction_id, card_id, user_id, merchant_id, mcc, valor, moeda, data_hora_utc, canal, pos_entry_mode, autorizacao_id. Registrar motivo_rejeicao 'CAMPO_OBRIGATORIO_AUSENTE'.
- Regra 2 (Tipos e formatos):
  • valor: numérico > 0; moeda: 'BRL'; data_hora_utc: ISO 8601; latitude/longitude: números válidos.
  • Se moeda != 'BRL', rejeitar com 'MOEDA_NAO_SUPORTADA'. Se valor <= 0, rejeitar com 'VALOR_INVALIDO'.
- Regra 3 (Normalização de horário): Converter data_hora_utc para data_hora_local usando fuso de uf_merchant quando fornecido; caso contrário manter UTC e marcar campo timezone_aplicado = 'UTC'. Derivar: hora_local (HH:mm), dia_semana (1=Seg..7=Dom), periodo_dia (manha|almoco|tarde|noite|madrugada por faixas 05:00–10:29, 10:30–14:59, 15:00–18:59, 19:00–22:59, 23:00–04:59).
- Regra 4 (MCC e canal): Normalizar mcc para string de 4 dígitos; canal deve ser um de {presencial, online}. Se diferente, rejeitar com 'CANAL_INVALIDO'.
- Regra 5 (POS entry): pos_entry_mode deve ser um de {chip, contactless, magstripe, manual, ecommerce}. Se ausente ou inválido, rejeitar com 'POS_ENTRY_INVALIDO'.
- Regra 6 (Geodados): Se latitude/longitude ausentes para canal presencial, manter mas marcar geoloc_ausente=true. Gerar geohash_7 quando lat/long válidos.
- Regra 7 (Saneamento de merchant): Remover espaços duplicados e caracteres especiais de merchant_nome; derivar merchant_nome_normalizado (lowercase sem acentos). Criar merchant_chave = hash(merchant_id || merchant_nome_normalizado).
- Regra 8 (Atributos derivados): Criar: valor_arredondado (2 casas), ticket_bucket (<=20, 20–40, 40–80, >80), eh_fim_de_semana (sab/dom), ano_mes (YYYY-MM), canal_presencial (boolean), pos_manual (boolean), pos_ecommerce (boolean).
- Regra 9 (Limites técnicos): Se valor > 5.000 BRL, rejeitar com 'VALOR_ACIMA_LIMITE_TECNICO'.
- Regra 10 (Parâmetros): Permitir sobrescrita via parametros_config: timezone_padrao, limite_tecnico_valor, definicao_periodos_dia. Ausência mantém defaults descritos.
1.3 Configurações do Agente

1.3.1 Especificação do Input

  • Mecanismo de Acionamento: Este agente é o ponto de partida do fluxo e deve ser acionado pelo envio de dados de transações via API. Na fase de testes, os dados serão enviados para o agente diretamente por upload de um arquivo JSON na interface da Prototipe AI, para acelerar o processo de validação.
  • Tipo do input: O input inicial para o fluxo é um arquivo JSON contendo uma ou mais transações de vale-refeição.
  • Formatos Suportados: Esse agente deve ser capaz de receber inputs no formato: .json.
  • Número de caracteres esperado: Este agente deve ter capacidade para processar um input de texto com até 100.000 caracteres.

1.3.2 Especificação do Output

  • Formato de output: O output deve ser um JSON com arrays de transacoes_validas e transacoes_rejeitadas, cada item contendo campos normalizados e atributos derivados ou motivos de rejeição.
  • Exemplo de Estrutura de Output:
     {
      "transacoes_validas": [
        {
          "transaction_id": "123456",
          "valor_arredondado": 49.99,
          "ticket_bucket": "40–80",
          "eh_fim_de_semana": false,
          "ano_mes": "2025-12",
          "canal_presencial": true,
          "pos_manual": false
        }
      ],
      "transacoes_rejeitadas": [
        {
          "transaction_id": "654321",
          "motivos_rejeicao": [
            {
              "codigo": "VALOR_INVALIDO",
              "descricao": "Valor da transação não pode ser menor ou igual a zero."
            }
          ]
        }
      ]
    } 
  • Número de caracteres esperado: O JSON final deve ser conciso e informativo, com um tamanho estimado em torno de 5.000 caracteres, podendo variar conforme o número de transações processadas.

1.3.3 Parâmetros de Geração

  • Modelo: GPT-5
  • Temperatura: 0.6

1.3.4 Ferramentas do Agente

  • Documentos: Não consulta documentos externos.
  • Calculadora: Utiliza lógica interna para cálculos de normalização e derivação de atributos.
  • Busca Online: Não utiliza.
  • Sistemas Externos: Não se conecta a sistemas externos.

1.3.5 Memória

1.3.6 Regras de Orquestração e Transição

Ao concluir sua execução, esse agente aciona o Agente de Sinalização de Risco por Regras Determinísticas (RF 2).

RF 2. Agente de Sinalização de Risco por Regras Determinísticas

2.1 Tarefa do Agente

Aplicar regras de negócio específicas de vale-refeição para identificar fraude evidente e gerar flags e escore de risco por regra.

2.2 Prompt ou Instruções do Agente
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo um JSON de transacoes_validas do agente anterior, com atributos derivados, e opcionalmente contexto: listas {mcc_permitidos[], merchant_restritos[], horarios_permitidos[], geofences_usuario[]}, politicas {limite_valor_transacao, limite_valor_dia, limite_qtd_transacoes_30min, janela_refeicao}, e metadados de sessão (ex.: tentativas_negadas_recentes, n_cartoes_por_device_30min).

# 2. Objetivo
Aplicar regras de negócio específicas de vale-refeição para identificar fraude evidente e gerar flags e escore de risco por regra.

# 3. Regras que você deve seguir para gerar sua resposta
- Parâmetros padrão (podem ser sobrescritos no input): limite_valor_transacao=80, limite_valor_dia=140, limite_qtd_transacoes_30min=3, janela_refeicao=[10:30–15:00], horario_noturno=[23:00–05:00], distancia_max_km=25.
- Regra A (Valor acima do limite unitário): Se valor > limite_valor_transacao, gerar FLAG 'VALOR_ACIMA_LIMITE' (sev=Média). Score +20.
- Regra B (Fracionamento/split): Se mesmo card_id no mesmo merchant em <= 2 minutos somando valor das últimas transações > limite_valor_transacao, FLAG 'FRACIONAMENTO' (Alta). Score +30.
- Regra C (Extrapolação diária): Se soma de valores no dia por user_id > limite_valor_dia, FLAG 'LIMITE_DIARIO_EXCEDIDO' (Média). Score +15.
- Regra D (Horário atípico): Se periodo_dia = madrugada ou fora de horarios_permitidos definidos, FLAG 'HORARIO_ATIPICO' (Baixa). Score +10.
- Regra E (MCC não elegível): Se mcc não em mcc_permitidos, FLAG 'MCC_NAO_ELEGIVEL' (Alta). Score +40.
- Regra F (Merchant restrito): Se merchant_id presente em merchant_restritos, FLAG 'MERCHANT_LISTA_RESTRITA' (Alta). Score +50.
- Regra G (Modo de entrada incompatível):
  • presencial com pos_manual=true -> 'MODO_ENTRADA_MANUAL' (Média) Score +20;
  • online com pos_entry_mode != ecommerce -> 'MODO_ECOMMERCE_INCOMPATIVEL' (Média) +15.
- Regra H (Card sharing por device): Se n_cartoes_por_device_30min > 3 no mesmo merchant, FLAG 'COMPARTILHAMENTO_CARTAO' (Alta). Score +30.
- Regra I (Saldo insuficiente informado): Se saldo_disponivel < valor, FLAG 'SALDO_INSUFICIENTE' (Alta). Score +40.
- Regra J (Tentativa forçada): Se existem ≥2 tentativas_negadas_recentes em ≤10min seguidas de aprovação com valor >= limite_valor_transacao, FLAG 'TENTATIVA_FORCADA' (Alta). Score +25.
- Regra K (Autonegócio/vinculação indevida): Se merchant_id em vinculos_restritos_do_usuario (quando fornecido), FLAG 'VINCULO_INDEVIDO' (Alta). Score +35.
- Consolidação de score: Somar scores das flags, limitar a 100. score_componentes deve mapear cada codigo de flag ao score adicionado.
- Evidências: Para cada flag, preencher evidencias com campos objetivos (ex.: valor, limite, mcc, horario, contagem_janela, soma_janela, device_id, distancia_km quando aplicável).
2.3 Configurações do Agente

2.3.1 Especificação do Input

  • Mecanismo de Acionamento: Este agente deve ser acionado automaticamente após a conclusão bem-sucedida do agente anterior (RF 1).
  • Tipo do input: Este agente deve ser apto a receber como input um JSON de transacoes_validas do agente anterior, com atributos derivados e contexto opcional.
  • Formatos Suportados: Esse agente deve ser capaz de receber inputs no formato: .json.
  • Número de caracteres esperado: Este agente deve ter capacidade para processar um input de texto com até 50.000 caracteres.

2.3.2 Especificação do Output

  • Formato de output: O output deve ser um JSON contendo flags de risco e escore por regra para cada transação.
  • Exemplo de Estrutura de Output:
     [
      {
        "transaction_id": "123456",
        "flags": [
          {
            "codigo": "VALOR_ACIMA_LIMITE",
            "severidade": "Média",
            "descricao": "Transação acima do limite permitido de 80 BRL.",
            "evidencias": {
              "valor": 100,
              "limite": 80
            }
          }
        ],
        "score_regras": 20
      }
    ] 
  • Número de caracteres esperado: O JSON final deve ser conciso e informativo, com um tamanho estimado em torno de 5.000 caracteres, podendo variar conforme o número de transações processadas e flags geradas.

2.3.3 Parâmetros de Geração

  • Modelo: GPT-5
  • Temperatura: 0.6

2.3.4 Ferramentas do Agente

  • Documentos: Não consulta documentos externos.
  • Calculadora: Utiliza lógica interna para cálculo de escore de risco.
  • Busca Online: Não utiliza.
  • Sistemas Externos: Não se conecta a sistemas externos.

2.3.5 Memória

2.3.6 Regras de Orquestração e Transição

Ao concluir sua execução, esse agente aciona o Agente de Agregação Temporal e Desvio de Padrão (RF 3).

RF 3. Agente de Agregação Temporal e Desvio de Padrão

3.1 Tarefa do Agente

Comparar a transação atual com o comportamento histórico resumido para detectar desvios abruptos e padrões repetitivos suspeitos.

3.2 Prompt ou Instruções do Agente
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo transações com flags/score do agente anterior e um historico_compacto opcional por user_id, card_id e merchant_id contendo: media_ticket_30d, desvio_ticket_30d, qtd_transacoes_7d, qtd_transacoes_30d, frequencia_media_diaria_30d, horario_predominante (faixa), raio_medio_km_trabalho (quando disponível), ultimo_local{lat,long,hora}, qtd_dias_sem_transacoes_30d, proporcao_transacoes_periodo{manha,almoco,tarde,noite,madrugada}.

# 2. Objetivo
Comparar a transação atual com o comportamento histórico resumido para detectar desvios abruptos e padrões repetitivos suspeitos.

# 3. Regras que você deve seguir para gerar sua resposta
- Regra T1 (Valor fora do padrão): Se desvio_ticket_30d > 0 e valor >= media_ticket_30d + 3*desvio_ticket_30d, FLAG 'VALOR_FORA_PADRAO_3SIGMA' (Média). +20.
- Regra T2 (Aumento súbito de frequência): Se frequencia nas últimas 2h >= 2x a frequencia_media_diaria_30d convertida para taxa/hora, FLAG 'AUMENTO_FREQUENCIA' (Média). +15.
- Regra T3 (Mudança de horário): Se periodo_dia atual diferente de horario_predominante e fora de janela_refeicao, FLAG 'MUDANCA_HORARIO' (Baixa). +10.
- Regra T4 (Padrão micropagamentos): ≥5 transações <= R$10 no mesmo merchant em 60min, FLAG 'MICROPAGAMENTOS_REPETITIVOS' (Média). +15.
- Regra T5 (Rota improvável): Se distância entre ultimo_local e transação atual > max(raio_medio_km_trabalho*3, distancia_max_km) quando ambos locais presentes, FLAG 'ROTA_IMPROVAVEL' (Alta). +25.
- Regra T6 (Reativação súbita): Se qtd_dias_sem_transacoes_30d >= 14 e agora ocorrem ≥3 transações em 30min, FLAG 'REATIVACAO_SUBITA' (Média). +15.
- Score temporal: Somar contribuições e limitar a 100. Novas flags devem conter evidencias objetivas (médias, desvios, contagens, distâncias).
3.3 Configurações do Agente

3.3.1 Especificação do Input

  • Mecanismo de Acionamento: Este agente deve ser acionado automaticamente após a conclusão bem-sucedida do agente anterior (RF 2).
  • Tipo do input: Este agente deve ser apto a receber como input transações com flags/score do agente anterior e um historico_compacto opcional.
  • Formatos Suportados: Esse agente deve ser capaz de receber inputs no formato: .json.
  • Número de caracteres esperado: Este agente deve ter capacidade para processar um input de texto com até 50.000 caracteres.

3.3.2 Especificação do Output

  • Formato de output: O output deve ser um JSON contendo novas flags de risco e escore temporal para cada transação.
  • Exemplo de Estrutura de Output:
     [
      {
        "transaction_id": "123456",
        "analysis_temporal": {
          "novas_flags": [
            {
              "codigo": "VALOR_FORA_PADRAO_3SIGMA",
              "severidade": "Média",
              "descricao": "Valor da transação fora do padrão normal para o usuário.",
              "evidencias": {
                "valor": 150,
                "media_ticket_30d": 50,
                "desvio_ticket_30d": 30
              }
            }
          ],
          "score_temporal": 20
        }
      }
    ] 
  • Número de caracteres esperado: O JSON final deve ser conciso e informativo, com um tamanho estimado em torno de 5.000 caracteres, podendo variar conforme o número de transações processadas e flags geradas.

3.3.3 Parâmetros de Geração

  • Modelo: GPT-5
  • Temperatura: 0.6

3.3.4 Ferramentas do Agente

  • Documentos: Não consulta documentos externos.
  • Calculadora: Utiliza lógica interna para cálculo de escore temporal e comparações históricas.
  • Busca Online: Não utiliza.
  • Sistemas Externos: Não se conecta a sistemas externos.

3.3.5 Memória

  • Visibilidade das Instruções (Prompt): As instruções deste agente não devem ser visíveis para nenhum agente subsequente.
  • Visibilidade da Resposta: A resposta gerada por este agente deve ser visível para o Agente de Decisão e Geração de Alerta (RF 4).

3.3.6 Regras de Orquestração e Transição

Ao concluir sua execução, esse agente aciona o Agente de Decisão e Geração de Alerta (RF 4).

RF 4. Agente de Decisão e Geração de Alerta

4.1 Tarefa do Agente

Consolidar flags e scores, decidir ação operacional e estruturar o alerta a responsáveis de fraude.

4.2 Prompt ou Instruções do Agente
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo transação enriquecida com flags e scores anteriores: score_regras, score_temporal, flags (todas), além de políticas de decisão opcionais: thresholds {bloqueio_imediato, alerta_alta, alerta_media}, regras_hard_block {MCC_NAO_ELEGIVEL, MERCHANT_LISTA_RESTRITA, SALDO_INSUFICIENTE, MODO_ENTRADA_MANUAL_EM_CENARIO_PROIBIDO}.

# 2. Objetivo
Consolidar flags e scores, decidir ação operacional e estruturar o alerta a responsáveis de fraude.

# 3. Regras que você deve seguir para gerar sua resposta
- Consolidação de score: score_total = min(100, score_regras + score_temporal).
- Hard block: Se existir qualquer flag em regras_hard_block (por padrão: MCC_NAO_ELEGIVEL, MERCHANT_LISTA_RESTRITA, SALDO_INSUFICIENTE) -> acao=bloquear_temporario, severidade=P1, sla_minutos=15.
- Thresholds padrão: alerta_alta≥80 -> P1 (revisar/bloquear); 60–79 -> P2 (revisar); 40–59 -> P3 (monitorar); <40 -> OK (aprovado).
- Priorização de motivos: Ordenar motivos_prioritarios por severidade (Alta>Média>Baixa) e score contribuído.
- Anonimização: Em campos_sensiveis_mascarados, mascarar user_id e card_id mantendo 4 últimos dígitos/ caracteres; não incluir dados pessoais além do necessário.
- Mensagens: titulo curto contendo codigo_principal e merchant_nome; evidencias_chave limitadas a até 6 itens objetivos (ex.: valor, limite, mcc, horario, contagem_30min, distancia_km).
- Canais sugeridos: Se severidade=P1 -> ['webhook','fila']; P2 -> ['fila']; P3 -> ['webhook']; OK -> [].
4.3 Configurações do Agente

4.3.1 Especificação do Input

  • Mecanismo de Acionamento: Este agente deve ser acionado automaticamente após a conclusão bem-sucedida do agente anterior (RF 3).
  • Tipo do input: Este agente deve ser apto a receber como input transação enriquecida com flags e scores anteriores e políticas de decisão opcionais.
  • Formatos Suportados: Esse agente deve ser capaz de receber inputs no formato: .json.
  • Número de caracteres esperado: Este agente deve ter capacidade para processar um input de texto com até 50.000 caracteres.

4.3.2 Especificação do Output

  • Formato de output: O output deve ser um objeto JSON contendo decisão por transação e estrutura de alerta.
  • Exemplo de Estrutura de Output:
     {
      "transaction_id": "123456",
      "score_total": 85,
      "severidade": "P1",
      "acao": "revisar",
      "recomendacao_operacional": "Revisar transação por suspeita de fraude.",
      "alerta": {
        "titulo": "Alerta de Fraude - Merchant XYZ",
        "mensagem": "Transação suspeita identificada para revisão imediata.",
        "evidencias_chave": {
          "valor": 150,
          "limite": 80,
          "mcc": "5812",
          "horario": "23:45",
          "contagem_30min": 4,
          "distancia_km": 30
        },
        "sla_minutos": 15,
        "canais_sugeridos": ["webhook", "fila"],
        "dados_minimos": {
          "transaction_id": "123456",
          "card_id": "****5678",
          "user_id": "****1234",
          "merchant_id": "987654",
          "valor": 150,
          "data_hora_local": "2025-12-21T23:45:00"
        },
        "campos_sensiveis_mascarados": {
          "user_id": "****1234",
          "card_id": "****5678"
        }
      }
    } 
  • Número de caracteres esperado: O JSON final deve ser conciso e informativo, com um tamanho estimado em torno de 5.000 caracteres, podendo variar conforme o número de transações processadas e flags geradas.

4.3.3 Parâmetros de Geração

  • Modelo: GPT-5
  • Temperatura: 0.6

4.3.4 Ferramentas do Agente

  • Documentos: Não consulta documentos externos.
  • Calculadora: Utiliza lógica interna para consolidação de scores e decisão operacional.
  • Busca Online: Não utiliza.
  • Sistemas Externos: O envio externo do alerta pode ser configurado na orquestração do fluxo como etapa de saída (ex.: webhook do sistema antifraude). Por se tratar de envio final do output, não é necessário um agente dedicado de execução de API.

4.3.5 Memória

  • Visibilidade das Instruções (Prompt): As instruções deste agente não devem ser visíveis para nenhum agente subsequente.
  • Visibilidade da Resposta: A resposta (decisão e alerta) é o entregável final e não é passada para outros agentes internos.

4.3.6 Regras de Orquestração e Transição

A execução deste agente finaliza o fluxo. O alerta gerado é o resultado que deve ser disponibilizado ao usuário.

© 2025 prototipe.ai. Todos os direitos reservados.