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

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

Como criar um agente de IA que analisa dados de transações financeiras, identificando padrões e oferecendo insights para otimização de carteiras.

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 Agente de IA para Análise de Dados de Transações Financeiras. 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 é transformar dados de transações financeiras em insights acionáveis, identificando padrões e oferecendo recomendações para otimização de carteiras de investimento.

2. Contexto e Problema

Cenário Atual

As instituições financeiras enfrentam desafios significativos ao lidar com grandes volumes de dados de transações. Há uma necessidade crescente de identificar padrões que possam informar decisões estratégicas sobre a alocação de recursos e a gestão de carteiras.

  • Identificação de padrões em grandes volumes de dados de transações financeiras.
  • Necessidade de insights para otimização de carteiras de investimento.

Atualmente, muitos desses processos são manuais ou baseados em sistemas legados que não conseguem acompanhar a dinâmica e a complexidade do mercado financeiro moderno.


Problemas Identificados

  • Volume de Dados: O grande volume de dados de transações torna a análise manual inviável e propensa a erros.
  • Insights Limitados: As ferramentas atuais frequentemente não conseguem identificar padrões emergentes ou oferecer insights acionáveis de maneira oportuna.
  • Otimização Ineficiente: Sem uma análise detalhada, as carteiras de investimento podem não estar otimizadas, levando a retornos subótimos.

3. Impactos Esperados

A implementação deste agente visa alcançar os seguintes resultados:

  • Automatizar a análise de dados de transações para identificar padrões de forma mais eficiente.
  • Prover insights acionáveis que ajudem na otimização de carteiras de investimento.
  • Reduzir o tempo e o esforço necessários para análises manuais, liberando recursos para outras atividades estratégicas.

4. Visão Geral da Solução

O agente de IA para análise de dados de transações financeiras processa grandes volumes de dados, identifica padrões e oferece insights para otimização de carteiras de investimento. 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 análise financeira.

A solução consiste em um fluxo de automação composto por três agentes de IA. O processo inicia com a preparação e validação dos dados de transações e termina com a geração de insights para carteiras de investimento.

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

Agentes Função Principal
Agente de Preparação e Validação de Dados de Transações (RF 1) Receber dados brutos de transações financeiras, padronizar campos e validar consistência.
Agente de Análise de Padrões em Transações Financeiras (RF 2) Identificar padrões, sazonalidades, recorrências e anomalias a partir do dataset padronizado.
Agente de Geração de Insights para Carteiras de Investimento (RF 3) Traduzir os padrões identificados em recomendações práticas para otimização de carteira.

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 Preparação e Validação de Dados de Transações

1.1 Tarefa do Agente

Receber dados brutos de transações financeiras, padronizar campos, validar consistência, deduplicar e produzir um dataset normalizado e auditável para análise.

1.2 Prompt ou Instruções do Agente
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo um dataset de transações financeiras em formato CSV ou JSON. Este dataset contém informações sobre transações financeiras que precisam ser padronizadas e validadas.

# 2. Objetivo
Padronizar e validar os dados de transações, criando um dataset normalizado e auditável para análise posterior.

# 3. Regras que você deve seguir para gerar sua resposta
- Exigir os campos mínimos: id_transacao, data, valor. Se ausentes, marcar a linha como inválida em data_quality.linhas_invalidas com motivo detalhado e não incluir em standardized_transactions.
- Normalizar data: converter para ISO-8601 (YYYY-MM-DDTHH:mm:ss±hh:mm), aplicando timezone_origem quando fornecido; se ausente, assumir UTC e registrar em metadata.regras_assumidas.
- Derivar campos temporais: ano, mes (1-12), dia (1-31), weekday (1=segunda...7=domingo) a partir de data_iso.
- Interpretar sinal de caixa: valores > 0 como 'entrada' e < 0 como 'saida'. Não alterar o módulo de valor; registrar valor_num como valor absoluto e sinal separadamente.
- Padronizar categorias: aplicar dicionario_categorias quando fornecido; se categoria ausente, definir 'sem_categoria' e registrar em data_quality.normalizacoes_aplicadas.categorias.
- Normalizar descrição: remover espaços excedentes, unificar caixa (title case), truncar a 280 caracteres preservando informação essencial; armazenar versão normalizada em descricao_norm sem apagar o original do relatório de qualidade.
- Moeda: manter código de moeda por transação; não converter valores. Se moeda ausente, usar moeda_padrao (se fornecida) e registrar suposição em metadata.
- Deduplicação: considerar duplicata quando houver colisão de fingerprint composta por (id_transacao) OU, na ausência de id confiável, pela combinação (data_iso até minuto, valor_num, sinal, conta, moeda). Incluir duplicatas em data_quality.duplicatas_identificadas e manter apenas a primeira ocorrência válida.
- Validação numérica: rejeitar linhas com valor não numérico ou igual a zero, registrando motivo; aceitar decimais com separador ponto ou vírgula (converter para ponto).
- Outliers e inconsistências: não excluir; apenas sinalizar em data_quality.linhas_invalidas quando valor_num for negativo com sinal 'entrada' ou positivo com 'saida'. Em casos de outliers (> 4x IQR por categoria preliminar), marcar em supressoes_ou_correcoes com tipo='flag_outlier' sem alterar valor.
- Integridade de ticker_ativo: manter somente tickers alfanuméricos e separadores padrão (., -); se inválido, mover para descricao_norm com tag '[ticker_invalido]' e limpar ticker_ativo.
- Garantir que o output seja determinístico: para qualquer ambiguidade, preferir 'registrar suposição em metadata' a modificar valores. 
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 um dataset de transações financeiras via API. Na fase de testes, o fluxo será iniciado pelo envio manual dos dados, que serão enviados para o agente diretamente por upload do arquivo na interface da Prototipe AI, para acelerar o processo de validação.
  • Tipo do input: O input inicial para o fluxo é um arquivo de dados de transações financeiras em formato CSV ou JSON.
  • Formatos Suportados: Esse agente deve ser capaz de receber dados nos formatos: .csv, .json.
  • Número de caracteres esperado: Este agente deve ter capacidade para processar um input de texto com até 500.000 caracteres.

1.3.2 Especificação do Output

  • Formato de output: O output deve ser um JSON estruturado contendo as transações padronizadas e informações de qualidade dos dados.
  • Exemplo de Estrutura de Output:
     {
      "standardized_transactions": [
        {
          "id_transacao": "123",
          "data_iso": "2025-12-10T06:40:00-03:00",
          "ano": 2025,
          "mes": 12,
          "dia": 10,
          "weekday": 3,
          "valor_num": 1000.00,
          "sinal": "entrada",
          "categoria_norm": "investimento",
          "descricao_norm": "Compra de Ações",
          "moeda": "BRL",
          "conta": "Conta Principal",
          "ticker_ativo": "PETR4"
        }
      ],
      "data_quality": {
        "linhas_totais": 1000,
        "linhas_validas": 995,
        "linhas_invalidas": [
          {
            "id_transacao": "124",
            "motivo": "valor não numérico"
          }
        ],
        "duplicatas_identificadas": ["125", "126"],
        "normalizacoes_aplicadas": {
          "categorias": 100,
          "datas": 1000,
          "descricoes": 995
        },
        "moedas_detectadas": ["BRL", "USD"],
        "supressoes_ou_correcoes": [
          {
            "id_transacao": "127",
            "campo": "descricao",
            "valor_original": "compra ",
            "valor_normalizado": "Compra"
          }
        ]
      },
      "metadata": {
        "timezone_aplicada": "America/Sao_Paulo",
        "moeda_padrao": "BRL",
        "regras_assumidas": {"timezone": "UTC"}
      }
    } 
  • Número de caracteres esperado: O JSON gerado terá um tamanho aproximado de 10.000 caracteres, variando conforme o número e a complexidade das 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: 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 Análise de Padrões em Transações Financeiras (RF 2).

RF 2. Agente de Análise de Padrões em Transações Financeiras

2.1 Tarefa do Agente

Identificar padrões, sazonalidades, recorrências, ciclos de caixa e anomalias a partir do dataset padronizado.

2.2 Prompt ou Instruções do Agente
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo um JSON padronizado contendo transações financeiras validadas e normalizadas. Este JSON é o resultado da etapa anterior de preparação e validação de dados.

# 2. Objetivo
Analisar o dataset padronizado para identificar padrões, sazonalidades, recorrências e anomalias que possam informar decisões estratégicas sobre a gestão de carteiras.

# 3. Regras que você deve seguir para gerar sua resposta
- Determinar período de análise a partir de data_iso mínima e máxima; calcular dias totais no período, inflows_total (soma de valor_num com sinal=entrada), outflows_total (sinal=saida) e saldo_liquido=infl - out.
- Detectar recorrências: considerar uma série recorrente quando houver 3+ ocorrências com intervalo mediano de 28-31 dias (mensal), 14-16 dias (quinzenal) ou 7 dias (semanal) e coeficiente de variação do intervalo <= 0,2; estimar próxima ocorrência como última_data + intervalo_mediano.
- Sazonalidade mensal: para cada categoria com pelo menos 5 ocorrências por mês, calcular variação_mensal_pct = (gasto_mes_atual - média_12m_categoria)/média_12m_categoria; se janela < 12m, usar toda a amostra e marcar caveat de amostra curta.
- Tendências por categoria: para janelas 30/90/180 dias, calcular taxa de crescimento aproximada como (soma_última_metade - soma_primeira_metade)/soma_primeira_metade; classificar significância como alta (|var|>=20% e n>=20), média (|var|>=10% e n>=10), baixa caso contrário.
- Concentração por fornecedor (merchant): agrupar por descricao_norm em saídas; calcular share_outflows_pct e o índice HHI somando quadrados das parcelas (em fração); sinalizar concentração elevada se HHI >= 0,18.
- Ciclos de caixa: calcular médias de inflow/outflow por weekday (1-7) e por mês (1-12); identificar efeitos de pagamento próximos ao 1º, 15º e último dia útil marcando picos de inflow > 1,5x média mensal.
- Anomalias: marcar como valor_extremo quando z-score dentro da categoria e mês for > 3 em módulo; fora_do_padrao_merchant quando um gasto com merchant excede 200% da mediana móvel de 3 ocorrências anteriores; data_incomum quando uma transação recorrente foge do intervalo esperado por > 3 dias.
- Amostras mínimas: ignorar métricas para grupos (categoria/merchant) com n < 5 observações; registrar caveat correspondente.
- Não imputar valores nem alterar o dataset; todas as inferências devem ser derivadas de standardized_transactions tal como recebido.
- Propagar avisos de data_quality (linhas_invalidas, duplicatas) para caveats, incluindo contagens e possíveis impactos nas métricas. 
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 padronizado, que corresponde ao dataset de transações financeiras validadas pelo agente anterior.
  • 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é 500.000 caracteres.

2.3.2 Especificação do Output

  • Formato de output: O output deve ser um JSON estruturado contendo o resumo da análise de padrões, sazonalidades, recorrências e anomalias.
  • Exemplo de Estrutura de Output:
     {
      "resumo": {
        "periodo_analise": {
          "inicio": "2025-01-01",
          "fim": "2025-12-10",
          "dias": 344
        },
        "inflows_total": 500000.00,
        "outflows_total": 450000.00,
        "saldo_liquido": 50000.00,
        "ticket_medio_saida": 450.00,
        "ticket_medio_entrada": 500.00
      },
      "padroes": {
        "recorrencias": [
          {
            "tipo": "mensal",
            "descricao": "Pagamento de Salário",
            "valor_medio": 5000.00,
            "desvio_relativo": 0.05,
            "proxima_ocorrencia_estimada": "2025-12-30"
          }
        ],
        "sazonalidade_mensal": [
          {
            "categoria_norm": "lazer",
            "mes": 12,
            "variacao_mensal_pct": 0.15
          }
        ],
        "tendencias_categoria": [
          {
            "categoria_norm": "alimentacao",
            "janela": 90,
            "cagr_pct": 0.10,
            "significancia": "media"
          }
        ],
        "concentracao_fornecedor": {
          "top_merchants": [
            {
              "descricao_norm": "Supermercado XYZ",
              "share_outflows_pct": 0.20
            }
          ],
          "hhi_outflows": 0.18
        },
        "ciclos_caixa": {
          "por_weekday": [
            {
              "weekday": 5,
              "inflow_medio": 10000.00,
              "outflow_medio": 8000.00,
              "saldo_medio": 2000.00
            }
          ],
          "por_mes": [
            {
              "mes": 12,
              "inflow_medio": 45000.00,
              "outflow_medio": 40000.00,
              "saldo_medio": 5000.00
            }
          ],
          "efeitos_pagamento": [
            {
              "dia_proximo_pagamento": 30,
              "impacto_esperado": "alto"
            }
          ]
        },
        "anomalias": [
          {
            "id_transacao": "128",
            "motivo": "valor_extremo",
            "zscore_ou_ratio": 3.5
          }
        ]
      },
      "caveats": [
        "Amostra curta para sazonalidade mensal em algumas categorias"
      ]
    } 
  • Número de caracteres esperado: O JSON gerado terá um tamanho aproximado de 10.000 caracteres, variando conforme a complexidade da análise.

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: Utiliza lógica interna para cálculos estatísticos e de padrões.
  • Busca Online: Não utiliza.
  • Sistemas Externos: Não utiliza.

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 Geração de Insights para Carteiras de Investimento (RF 3).

RF 3. Agente de Geração de Insights para Carteiras de Investimento

3.1 Tarefa do Agente

Traduzir os padrões identificados em recomendações práticas para otimização de carteira, rebalanceamento, gestão de liquidez e disciplina de aportes.

3.2 Prompt ou Instruções do Agente
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo um JSON com padrões e anomalias identificados a partir de transações financeiras. Este JSON é o resultado da análise de padrões do agente anterior.

# 2. Objetivo
Traduzir os padrões identificados em recomendações práticas para otimização de carteira de investimentos, focando em rebalanceamento, gestão de liquidez e disciplina de aportes.

# 3. Regras que você deve seguir para gerar sua resposta
- Basear recomendações nos padrões: aumentar caixa quando volatilidade de outflows ou concentração de despesas recorrentes for elevada; sugerir DCA quando houver inflows previsíveis (recorrências de entrada) e saldo líquido positivo consistente.
- Buffer de liquidez: recomendar buffer mínimo = max(3 meses de outflows_médios, min_caixa_pct das restricoes, 10% da carteira) ajustado por tolerancia_risco (baixa: +5pp, alta: -5pp, sem ultrapassar 5%-30%).
- Rebalanceamento: propor alvos por classe respeitando max_classe_pct quando fornecido; sugerir ação quando desvio |peso_atual - peso_alvo| > max(2pp, 20% do peso_alvo). Priorizar vendas de classes acima do alvo e compras das abaixo.
- Concentração: se HHI_outflows alto, recomendar diversificação de despesas críticas (ex.: alternar fornecedores) e refletir isso na necessidade de caixa maior; se concentração por ativo/classe na carteira exceder limite, propor redução gradual.
- Sequenciamento de execução: ordenar recomendações por impacto: (1) ajuste de caixa/buffer, (2) redução de riscos excessivos (concentração, duration), (3) realocação fina. Incluir ranges percentuais e janelas (por exemplo, executar em 2-3 levas semanais).
- Aportes recorrentes: quando recorrencias de entrada forem mensais/quinzenais/semanais, recomendar percentual fixo de aporte por janela (ex.: 30-40% do excedente de caixa por mês) alinhado com datas de maior inflow.
- Alertas: sinalizar categorias com tendência de alta de gastos (>20% em 90 dias) que pressionem liquidez; sugerir teto de gasto e revisão de contratos/fornecedores.
- Tributação e custos: não calcular impostos; apenas orientar decisões para minimizar giro: evitar venda de posições com menos de 180 dias (ou critério informado em tributacao_pais) salvo necessidade de risco/liquidez; destacar custos de transação quando a soma superar 0,5% do montante rebalanceado.
- Compatibilidade com perfil: para tolerancia_risco baixa, limitar exposição a renda variável/alto risco a <= 25%; média <= 50%; alta até 80%, salvo restricoes explícitas. Ajustar pesos-alvo de acordo.
- Gatilhos de revisão: definir next_review_trigger como o mais cedo entre (chegada de novos dados de transações) e (30 dias); se ocorrer anomalia relevante (>3 z-score em saídas), recomendar revisão imediata.
- Declaração de escopo: incluir nota de que não se trata de aconselhamento financeiro personalizado; recomendações são baseadas nos dados e parâmetros fornecidos. 
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 com padrões e anomalias identificados a partir das transações financeiras.
  • 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.

3.3.2 Especificação do Output

  • Formato de output: O output deve ser um documento em formato **Markdown** contendo as recomendações práticas para otimização de carteira.
  • Exemplo de Estrutura de Output:
     # Resumo Executivo
    
    - **Alterações de Alocação:**
      - Aumentar caixa para 15% da carteira devido à alta volatilidade de saídas.
      - Reduzir exposição a "Supermercado XYZ"; diversificar fornecedores.
    
    - **Plano de Rebalanceamento:**
      - Executar em 2-3 levas semanais, priorizando ajustes de caixa e redução de riscos excessivos.
    
    - **Gestão de Liquidez:**
      - Recomendar buffer de liquidez mínimo de 20% da carteira, ajustado por risco.
    
    - **Alertas de Risco:**
      - Categoria 'Lazer' com tendência de alta; revisar contratos.
    
    - **Considerações Tributárias e de Custos:**
      - Evitar venda de posições com menos de 180 dias.
    
    - **Próximos Passos e Gatilhos de Revisão:**
      - Revisão em 30 dias ou ao receber novos dados de transações. 
  • Número de caracteres esperado: O documento gerado terá um tamanho aproximado de 5.000 caracteres, podendo variar conforme a complexidade das recomendações.

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 cálculos de rebalanceamento e liquidez.
  • 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 é o entregável final e não é passada para outros agentes internos.

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

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

© 2025 prototipe.ai. Todos os direitos reservados.