Agente de IA para Análise de Fraude em Transações Financeiras

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

Como criar um agente de IA que analisa transações financeiras em busca de padrões suspeitos ou anomalias que possam indicar fraude.

Biblioteca de Prompts e Agentes

1. Propósito e Escopo

Este documento define todos os prompts, configurações de memória, transição entre estados, ferramentas como chamadas a sistemas externos e demais requisitos funcionais para o Fluxo de Agentes "Análise de Fraude em Transações Financeiras", uma solução de automação projetada para detectar fraudes em tempo real. 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 é identificar padrões suspeitos ou anomalias em transações financeiras que possam indicar fraude, utilizando algoritmos de machine learning para melhorar a precisão da detecção e reduzir falsos positivos.

2. Contexto e Problema

Cenário Atual

No cenário atual, as instituições financeiras enfrentam desafios significativos na identificação de fraudes devido ao volume e à complexidade das transações. Problemas específicos incluem:

  • Detecção de fraudes em tempo real para evitar perdas financeiras.
  • Identificação de padrões complexos que podem não ser óbvios para analistas humanos.
  • Redução de falsos positivos que podem gerar alertas desnecessários.

As abordagens tradicionais muitas vezes falham em capturar a sutileza dos padrões de fraude moderna, resultando em alta taxa de falsos positivos ou em fraudes não detectadas.


Problemas Identificados

  • Complexidade dos padrões de fraude: A fraude financeira evolui constantemente, tornando difícil para sistemas tradicionais detectá-la de forma eficaz.
  • Volume de dados: O grande volume de transações diárias torna inviável a análise manual por parte dos analistas.
  • Falsos Positivos: Alertas excessivos podem sobrecarregar as equipes de análise e gerar custos desnecessários.

3. Impactos Esperados

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

  • Reduzir a taxa de fraudes em pelo menos 70%.
  • Aumentar a precisão na detecção de fraudes complexas.
  • Diminuir o número de falsos positivos, permitindo que as equipes se concentrem em casos realmente suspeitos.
  • Melhorar a eficiência operacional das equipes de segurança financeira.

4. Visão Geral da Solução

O agente de IA para análise de fraude em transações financeiras processa dados de transações em tempo real, aplicando algoritmos de machine learning para identificar padrões suspeitos ou anomalias. A seguir são detalhadas todas as regras de negócio e especificações funcionais necessárias para que esse agente atue como um assistente útil e autônomo na detecção de fraudes financeiras.

A solução consiste em um fluxo de automação composto por 5 agentes de IA. O processo inicia com a preparação dos parâmetros de consulta e termina com a emissão de um alerta padronizado em caso de detecção de fraude.

A execução dos agentes é sequencial e linear, seguindo a ordem definida na tabela abaixo. O fluxo inclui etapas condicionais que são executadas apenas se critérios específicos forem atendidos, conforme detalhado após a tabela.

Agentes Função Principal
Agente de Preparação de Parâmetros de Consulta (RF 1) Receber a transação em tempo real e produzir parâmetros de consulta padronizados.
Agente de Execução de Consultas em Banco de Dados (RF 2) Realizar conexão com o data lake/warehouse para obter histórico recente.
Agente de Engenharia de Sinais de Risco (RF 3) Transformar a transação atual e o histórico em sinais de risco.
Agente de Pontuação e Decisão de Risco (RF 4) Converter sinais em pontuação e gerar recomendação de ação.
Agente de Priorização e Emissão de Alerta (RF 5) Gerar alerta padronizado conforme nível de risco e contexto operacional.


Regras de Execução Condicional ou Edges

  • Ativação do Agente de Priorização e Emissão de Alerta (RF 5): Este agente só será executado se o nível de risco calculado pelo Agente de Pontuação e Decisão de Risco (RF 4) for "alto" ou "médio". Caso contrário, o fluxo é encerrado sem emissão de alerta.

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.

Ver Agente na Prototipe AI

6. Requisitos Funcionais

RF 1. Agente de Preparação de Parâmetros de Consulta

1.1 Tarefa do Agente

Receber a transação em tempo real e produzir parâmetros de consulta padronizados para recuperar histórico e perfil do cliente, contrapartes, dispositivos e padrões recentes.

1.2 Prompt ou Instruções do Agente 
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo uma transação financeira em tempo real. Este é um registro detalhado da transação, incluindo informações do cliente, valor e método de pagamento.

# 2. Objetivo
Produzir parâmetros de consulta padronizados para recuperar histórico e perfil do cliente, contrapartes, dispositivos e padrões recentes.

# 3. Regras que você deve seguir para gerar sua resposta
- Se 'cliente_id' estiver ausente, definir 'cliente_id' como null e manter o restante dos parâmetros; transações sem 'cliente_id' não bloqueiam a consulta, mas devem manter 'contas' e 'contrapartes'.
- Definir janela_tempo_horas = 720 (30 dias) para histórico padrão; se metodo_pagamento in ["cartao_credito","cartao_debito"], aumentar para 1440 (60 dias); se valor >= 5x mediana estimada (quando desconhecida, usar 1000 BRL como mediana provisória), definir 2160 (90 dias).
- Normalizar IP para IPv4/IPv6 textual; se ausente, não incluir em 'identificadores_rede'.
- Se 'destino_conta_id' iniciar com 'chave:' ou padrão de chave PIX, adicionar em 'contrapartes' exatamente essa chave normalizada (minúsculas, sem espaços).
- Definir 'moeda_base' com a moeda da transação; se ausente, 'BRL'.
- Incluir flags booleanas 'incluir_mcc', 'incluir_pix_chaves', 'incluir_geo' conforme presença dos respectivos dados na transação.
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 recebimento de dados de transação via API em tempo real. Na fase de testes, o fluxo será iniciado pelo envio manual dos dados, que 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 JSON detalhado da transação financeira.
  • 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é 5.000 caracteres.

1.3.2 Especificação do Output

  • Formato de output: O output deve ser um JSON contendo os parâmetros de consulta padronizados.
  • Exemplo de Estrutura de Output: 
     {"cliente_id":"C001","contas":["A123"],"contrapartes":["B789"],"identificadores_dispositivo":["D555"],"identificadores_rede":["203.0.113.10"],"janela_tempo_horas":720,"limite_eventos":1000,"moeda_base":"BRL","incluir_mcc":true,"incluir_pix_chaves":true,"incluir_geo":true}
  • Número de caracteres esperado: O JSON gerado deve ser claro e direto, com um tamanho estimado em 1.000 caracteres.

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: Não utiliza.
  • 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 Execução de Consultas em Banco de Dados (RF 2).

RF 2. Agente de Execução de Consultas em Banco de Dados

2.1 Tarefa do Agente

Realizar conexão com o data lake/warehouse transacional para obter histórico recente do cliente, contrapartes, dispositivos e geolocalizações.

2.2 Prompt ou Instruções do Agente 
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo parâmetros de consulta padronizados para recuperar histórico e perfil do cliente, contrapartes, dispositivos e padrões recentes.

# 2. Objetivo
Realizar conexão com o data lake/warehouse transacional para obter histórico recente do cliente, contrapartes, dispositivos e geolocalizações.

# 3. Regras que você deve seguir para gerar sua resposta
- Utilize os parâmetros recebidos para consultar o data lake/warehouse e recuperar dados relevantes.
- Assegure-se de que todas as consultas sejam otimizadas para minimizar o tempo de resposta e o uso de recursos.
- Garanta que os dados retornados estejam no formato esperado, conforme definido nos requisitos do fluxo.
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 do agente anterior (RF 1).
  • Tipo do input: Este agente deve ser apto a receber como input um JSON com parâmetros de consulta padronizados.
  • 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 até 1.000 caracteres.

2.3.2 Especificação do Output

  • Formato de output: O output deve ser um JSON contendo o histórico recente do cliente, contrapartes, dispositivos e geolocalizações.
  • Exemplo de Estrutura de Output: 
     {"historico_transacoes":[...],"perfil_cliente":{"mediana_valor":820.00,"p95_valor":2400.00,"horas_pico":[8,12,18],"mcc_frequentes":["5411","6011"],"canal_frequente":"app","pais_frequente":"BR","contas_associadas":["A123"],"dispositivos_confiaveis":["D555"],"ips_confiaveis":["203.0.113.10"]},"historico_dispositivos":[...],"historico_ips":[...],"geo_recente":[...],"primeira_transacao_destino":true}
  • Número de caracteres esperado: O JSON gerado terá um tamanho aproximado de 2.000 caracteres, podendo aumentar conforme o número de dados retornados.

2.3.3 Parâmetros de Geração

  • Modelo: GPT-5
  • Temperatura: 0.6

2.3.4 Ferramentas do Agente

  • Documentos: Não consulta.
  • Calculadora: Não utiliza.
  • Busca Online: Não utiliza.
  • Sistemas Externos: Conecta-se ao data lake/warehouse para execução de consultas.

2.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 Engenharia de Sinais de Risco (RF 3).

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

Ao concluir sua execução, esse agente aciona o Agente de Engenharia de Sinais de Risco (RF 3).

RF 3. Agente de Engenharia de Sinais de Risco

3.1 Tarefa do Agente

Transformar a transação atual e o histórico em sinais/variáveis de risco normalizadas e explicáveis.

3.2 Prompt ou Instruções do Agente 
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo a transação atual e o histórico recente do cliente, contrapartes, dispositivos e geolocalizações.

# 2. Objetivo
Transformar a transação atual e o histórico em sinais/variáveis de risco normalizadas e explicáveis.

# 3. Regras que você deve seguir para gerar sua resposta
- Calcular valor_zscore = (valor - mediana_valor) / (1.4826 * MAD); se MAD indisponível, usar p95_valor como escala: (valor - mediana) / (p95_valor - mediana), truncado em [-5,5]. Se histórico inexistente, definir valor_zscore = 0 e marcar 'perfil_desconhecido':true em 'derivados'.
- valor_relacao_p95 = valor / max(p95_valor, 1). Se p95_valor ausente, usar 1 para evitar divisão por zero.
- desvio_horario = true se hora da transação não pertence a 'horas_pico'. Determinar faixa_horaria: madrugada[0-5], manha[6-11], tarde[12-17], noite[18-23].
- nova_contraparte = true se 'destino_conta_id' ou chave PIX não aparece em historico_transacoes dos últimos 90 dias.
- geo_vel_kmh: se houver geo atual e geo_recente mais próxima em até 24h, velocidade = distância_km / delta_horas; se > 500 km/h, marcar geo_vel_kmh como valor calculado; se dados insuficientes, definir como null.
- device_mismatch = true se device_id não está em dispositivos_confiaveis e existe dispositivo confiável pregresso no mesmo canal.
- ip_mismatch = true se IP não está em ips_confiaveis e existe IP confiável pregresso no mesmo canal.
- mcc_atipico = true se mcc presente e não pertence a mcc_frequentes; se pagamento PIX sem mcc, manter como null.
- burst_30min = número de transações do cliente nas últimas 0.5 horas; se >= 3 e soma_valores >= 2x mediana_valor, manter o número; caso contrário, 0.
- split_suspeito = true se houver 3+ transações para mesma contraparte em <= 30min com valores individuais < p95_valor mas soma >= 1.5x p95_valor.
- pais_atipico = true se pais != pais_frequente e não há viagem recente inferida por geo.
- canal_atipico = true se canal != canal_frequente.
- primeira_transacao_destino = usar flag do histórico; se ausente, inferir por contagem de ocorrências = 0.
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 do agente anterior (RF 2).
  • Tipo do input: Este agente deve ser apto a receber como input um JSON combinando a transação atual e o histórico recente.
  • 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 até 3.000 caracteres.

3.3.2 Especificação do Output

  • Formato de output: O output deve ser um JSON contendo os sinais/variáveis de risco normalizadas e explicáveis.
  • Exemplo de Estrutura de Output: 
     {"signals":{"valor_zscore":1.85,"valor_relacao_p95":0.52,"desvio_horario":true,"nova_contraparte":true,"geo_vel_kmh":780,"device_mismatch":false,"ip_mismatch":false,"mcc_atipico":true,"burst_30min":4,"split_suspeito":false,"pais_atipico":false,"canal_atipico":false,"primeira_transacao_destino":true},"derivados":{"faixa_horaria":"madrugada","bucket_valor":"alto","janela_considerada_horas":720}}
  • Número de caracteres esperado: O JSON gerado terá um tamanho aproximado de 1.500 caracteres.

3.3.3 Parâmetros de Geração

  • Modelo: GPT-5
  • Temperatura: 0.6

3.3.4 Ferramentas do Agente

  • Documentos: Não consulta.
  • Calculadora: Utiliza lógica interna para calcular sinais de risco.
  • Busca Online: Não utiliza.
  • Sistemas Externos: Não utiliza.

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 Pontuação e Decisão de Risco (RF 4).

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

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

RF 4. Agente de Pontuação e Decisão de Risco

4.1 Tarefa do Agente

Converter sinais em pontuação 0-100, classificar nível de risco e gerar recomendação de ação com motivos explicáveis, controlando falsos positivos.

4.2 Prompt ou Instruções do Agente 
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo sinais/variáveis de risco normalizadas e explicáveis.

# 2. Objetivo
Converter sinais em pontuação 0-100, classificar nível de risco e gerar recomendação de ação com motivos explicáveis, controlando falsos positivos.

# 3. Regras que você deve seguir para gerar sua resposta
- Atribuir pontos por sinal (somar, truncar em 0-100):
  • nova_contraparte: +20 se true.
  • primeira_transacao_destino: +15 se true.
  • geo_vel_kmh: +25 se valor != null e > 500; +10 se entre 300-500.
  • valor_zscore: +15 se >= 3; +8 se entre 2 e 3.
  • mcc_atipico: +10 se true.
  • burst_30min: +10 se >=3.
  • split_suspeito: +20 se true.
  • ip_mismatch: +8 se true.
  • device_mismatch: +8 se true.
  • desvio_horario: +5 se true.
  • pais_atipico: +10 se true.
  • canal_atipico: +5 se true.
- Mitigações para reduzir falsos positivos (subtrair antes de classificar, não deixando score < 0):
  • -10 se device_mismatch == false e device_id ∈ dispositivos_confiaveis.
  • -10 se ip_mismatch == false e ip ∈ ips_confiaveis.
  • -8 se valor_relacao_p95 <= 0.5 e não houver burst_30min.
  • -5 se canal == canal_frequente e desvio_horario == false.
- Classificação por limiar do score final: baixo(0-39), medio(40-69), alto(70-100).
- Decisão:
  • "aprovar" se risk_level == baixo.
  • "revisar" se risk_level == medio.
  • "negar" se risk_level == alto e existirem pelo menos dois motivos fortes presentes entre: geo_vel_kmh>500, split_suspeito, nova_contraparte & primeira_transacao_destino simultâneas; caso contrário, "revisar".
- Preencher 'motivos' com rótulos legíveis apenas para sinais que efetivamente contribuíram com pontos líquidos positivos.
- Preencher 'mitigacoes_anti_fp' com rótulos correspondentes às reduções aplicadas.
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 do agente anterior (RF 3).
  • Tipo do input: Este agente deve ser apto a receber como input um JSON com sinais/variáveis de risco normalizadas e explicáveis.
  • 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 até 1.500 caracteres.

4.3.2 Especificação do Output

  • Formato de output: O output deve ser um JSON contendo a pontuação de risco, nível de risco e recomendação de ação.
  • Exemplo de Estrutura de Output: 
     {"risk_score":78,"risk_level":"alto","decision":"revisar","motivos":["Primeira transação para esta contraparte","Velocidade geográfica incompatível"],"mitigacoes_anti_fp":["Dispositivo confiável"],"tabela_pesos":{"nova_contraparte":20,"primeira_transacao_destino":15,"geo_vel_kmh":25,"valor_zscore":15,"mcc_atipico":10,"burst_30min":10,"split_suspeito":20,"ip_mismatch":8,"device_mismatch":8,"desvio_horario":5,"pais_atipico":10,"canal_atipico":5},"limiares":{"baixo":0-39,"medio":40-69,"alto":70-100}}
  • Número de caracteres esperado: O JSON gerado terá um tamanho aproximado de 1.000 caracteres.

4.3.3 Parâmetros de Geração

  • Modelo: GPT-5
  • Temperatura: 0.6

4.3.4 Ferramentas do Agente

  • Documentos: Não consulta.
  • Calculadora: Utiliza lógica interna para calcular pontuação de risco e recomendações.
  • Busca Online: Não utiliza.
  • Sistemas Externos: Não utiliza.

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 gerada por este agente deve ser visível para o Agente de Priorização e Emissão de Alerta (RF 5).

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

Ao concluir sua execução, esse agente aciona o Agente de Priorização e Emissão de Alerta (RF 5) se o nível de risco for "alto" ou "médio".

RF 5. Agente de Priorização e Emissão de Alerta

5.1 Tarefa do Agente

Gerar objeto de alerta padronizado, com prioridade e SLA conforme nível de risco e contexto operacional, evitando duplicidades.

5.2 Prompt ou Instruções do Agente 
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo a pontuação de risco, nível de risco e recomendação de ação.

# 2. Objetivo
Gerar objeto de alerta padronizado, com prioridade e SLA conforme nível de risco e contexto operacional, evitando duplicidades.

# 3. Regras que você deve seguir para gerar sua resposta
- Mapear prioridade pela matriz: risk_level baixo -> P3 (SLA 240 min); médio -> P2 (SLA 60 min); alto -> P1 (SLA 15 min). Se decision == "negar", manter P1 com SLA 10 min.
- Gerar chave_dedup = concat(cliente_id, destino_normalizado, data(YYYY-MM-DD), metodo_pagamento) separada por '|'. Se alerta igual existir em janela de 60 min, não emitir novo: apenas referenciar id_alerta existente no campo 'relacionado_a'.
- canal_roteamento: 'fraude_realtime' para alto; 'fraude_triagem' para médio; 'fraude_monitoramento' para baixo.
- Summário deve conter: nível de risco, característica mais forte (motivo top-1) e identificador do destino/merchant.
- Incluir 'contexto.signals' e 'derivados' completos para auditoria.
- Garantir que todos os campos principais estejam presentes; se algum for null, incluir 'observacoes' descrevendo a ausência de dados críticos.
5.3 Configurações do Agente

5.3.1 Especificação do Input

  • Mecanismo de Acionamento: Este agente deve ser acionado automaticamente após a conclusão do agente anterior (RF 4) se o nível de risco for "alto" ou "médio".
  • Tipo do input: Este agente deve ser apto a receber como input um JSON com a pontuação de risco, nível de risco e recomendação de açã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 até 1.000 caracteres.

5.3.2 Especificação do Output

  • Formato de output: O output deve ser um JSON contendo o objeto de alerta padronizado.
  • Exemplo de Estrutura de Output: 
     {"alerta":{"id_alerta":"ALRT-T123","prioridade":"P1","sla_min":15,"canal_roteamento":"fraude_realtime","chave_dedup":"C001|B789|2025-12-23|PIX","summario":"Risco alto para primeira transação ao destino B789 com velocidade geográfica anômala","campos_principais":{"id_transacao":"T123","cliente_id":"C001","valor":1250.75,"metodo_pagamento":"PIX","risk_score":78,"risk_level":"alto","decision":"revisar"},"motivos":["Primeira transação para esta contraparte","Velocidade geográfica incompatível"],"contexto":{"signals":{...},"derivados":{...}}}}
  • Número de caracteres esperado: O JSON gerado terá um tamanho aproximado de 2.000 caracteres.

5.3.3 Parâmetros de Geração

  • Modelo: GPT-5
  • Temperatura: 0.6

5.3.4 Ferramentas do Agente

  • Documentos: Não consulta.
  • Calculadora: Utiliza lógica interna para calcular prioridade e SLA.
  • Busca Online: Não utiliza.
  • Sistemas Externos: Não utiliza.

5.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 é o entregável final e não é passada para outros agentes internos.

5.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.

Posts Relacionados

© 2025 prototipe.ai. Todos os direitos reservados.