Agente de IA para Liquidação Automatizada de Transações

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

Como criar um agente de IA que automatiza o processo de liquidação de transações financeiras.

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, consulta a documentos e demais requisitos funcionais para o Fluxo de Agentes "Liquidação Automatizada de Transações", uma solução de automação projetada para assegurar que todos os passos necessários sejam seguidos de acordo com os regulamentos. 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 é automatizar o processo de liquidação de transações financeiras, garantindo a conformidade regulatória e a documentação completa do processo.

2. Contexto e Problema

Problemas Específicos

O processo atual de liquidação de transações financeiras enfrenta diversos desafios que este agente visa resolver:

  • Processos manuais demorados e sujeitos a erro durante a liquidação de transações.
  • Necessidade de aderência estrita a regulamentos que podem ser complexos e variados.
  • Falta de rastreabilidade e documentação completa do processo de liquidação.

Estes problemas são comuns em instituições financeiras que lidam com um grande volume de transações diariamente, exigindo precisão e conformidade em cada operação.

3. Impactos Esperados

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

  • Reduzir o tempo de liquidação em pelo menos 70%, eliminando etapas manuais.
  • Assegurar a conformidade regulatória em todas as transações processadas.
  • Prover documentação e rastreabilidade completa de todas as etapas do processo de liquidação.
  • Diminuir o risco de erros humanos e aumentar a eficiência operacional.

4. Visão Geral da Solução

O agente de IA para liquidação automatizada de transações processa dados de transações financeiras, aplica regras regulatórias em cada etapa e gera documentação rastreável de todo o processo. 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 liquidação de transações que seguem as especificidades da sua instituição.

A solução consiste em um fluxo de automação composto por 10 agentes de IA. O processo inicia com a padronização e validação das transações de entrada e termina com a produção de um pacote de auditoria completo.

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 Padronização e Validação de Entrada Receber transações brutas e padronizar o payload conforme esquema único.
Agente de Preparação de Parâmetros de Consulta Construir parâmetros prontos para consultas a bases internas de dados.
Agente de Execução de Consultas em Banco de Dados Realizar conexão com banco de dados corporativos para obter dados necessários.
Agente de Preparação de Chamadas de Verificação Externa Preparar chamadas para serviços externos de conformidade.
Agente de Execução de Chamada à API (Conformidade Externa) Executar chamadas às APIs de conformidade e diretórios externos.
Agente de Conformidade e Decisão de Roteamento de Liquidação Aplicar regras regulatórias e operacionais para decidir se liquida, retém ou rejeita.
Agente de Geração de Mensagens e Payloads de Liquidação Gerar instruções de liquidação em formatos requeridos.
Agente de Execução de Chamada à API (Envio de Instruções) Enviar mensagens/payloads gerados aos sistemas de liquidação.
Agente de Reconciliação e Confirmação Inicial Conciliar respostas de aceite/erro de sistemas de destino.
Agente de Documentação e Trilha de Auditoria Produzir documentação automática e rastreável de ponta a ponta da liquidação.

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 Padronização e Validação de Entrada

1.1 Tarefa do Agente

Receber transações brutas e padronizar o payload conforme esquema único, validando integridade, completude e elegibilidade básica para liquidação.

1.2 Prompt ou Instruções do Agente
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo um JSON de lote de transações com campos informados pelo usuário/sistema de origem.

# 2. Objetivo
Padronizar o payload conforme esquema único, validando integridade, completude e elegibilidade básica para liquidação.

# 3. Regras que você deve seguir para gerar sua resposta
- Aceite apenas JSON válido; se inválido, produza validation_summary com erro fatal e normalized_transactions vazio.
- Aplique esquema de campos: transaction_id (string), trade_date (ISO 8601 yyyy-mm-dd), value_date/settlement_date (ISO 8601), instrument_type (equity, bond, fx, deriv, cash), currency (ISO 4217), amount (decimal; use exponent conforme moeda), buyer/seller (party_id, lei opcional), accounts (iban/aba/cca conforme país), bic (8 ou 11), settlement_system (TARGET2, CLS, DTC, B3, Euroclear, Clearstream etc.), venue/market (MIC opcional), priority (normal/alta), instrucciones_especiais (string opcional).
- Normalize: trim espaços, upper-case para códigos (moeda, BIC, MIC), remover caracteres não numéricos em IBAN/ABA mantendo verificação de dígitos quando aplicável; para IBAN valide comprimento por país; para ABA 9 dígitos; para CLABE 18; para CBLC/B3 use 8-10 conforme padrão.
- Validar obrigatórios por tipo: cash e securities exigem settlement_date, currency, amount, origem/destino de contas; DvP exige conta custódia válida e código de custodiante; FX exige legs ou par de moedas e lado de compra/venda; derivativos: verifique clearing_house e conta de margem.
- Calcule settlement_date proposta: se ausente, derive a partir de trade_date + padrão (T+2 equities, T+1 US equities, T+2 bonds, FX spot T+2 salvo pares com T+1); ao calcular, não permita finais de semana; se calendário for fornecido, pule feriados do par país/moeda/mercado.
- Determine precision de amount usando exponent da moeda (ex.: JPY 0, USD/EUR 2); arredonde half-up para o exponent; se o input divergir, registre ajuste em validation_summary.
- Detecte duplicidades: se houver transações com mesmo transaction_id ou mesmo hash de [party_ids, amount, currency, settlement_date] dentro do lote, marque duplicate=true e inclua em validation_summary.
- Marque fx_conversion_needed=true quando currency da origem da conta diferir da moeda de liquidação e não houver par/leg explícito.
- Netting: agrupe candidatos por [counterparty, currency, settlement_date, settlement_system, instrument_type]; se grupo tiver 2+ itens e type permitir netting, set netting_candidate=true; calcule soma por grupo e guarde group_key.
- Defina cutoff_risk=true quando settlement_date for data atual e horário atual a menos de 60 minutos do cutoff padrão do sistema (se cutoff não conhecido ainda, deixe pending_cutoff=true para resolução posterior).
- Defina requires_aml_screening=true quando parte for nova (party_id sem LEI válido 20 caracteres alfanuméricos) ou quando valor >= limiar regional padrão (ex.: 10k USD/EUR) ou país de alto risco presente no endereço se fornecido.
- Saídas devem incluir reference_keys com listas únicas para facilitar consultas externas: leis, bics, contas, moedas, venues, sistemas, países. 
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 JSON de lote de transações 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 JSON na interface da Prototipe AI, para acelerar o processo de validação.
  • Tipo do input: O input inicial para o fluxo é um JSON de lote de 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é 150.000 caracteres.

1.3.2 Especificação do Output

  • Formato de output: O output deve ser um objeto JSON com: normalized_transactions (array padronizado), validation_summary (lista de erros/alertas por transação), gating_flags (por transação: requires_aml_screening, requires_kyc_update, fx_conversion_needed, cutoff_risk, missing_static_data, netting_candidate), reference_keys (listas deduplicadas de LEIs, BICs, contas, moedas, venues, sistemas).
  • Exemplo de Estrutura de Output:
     {
      "normalized_transactions": [...],
      "validation_summary": [...],
      "gating_flags": [...],
      "reference_keys": [...]
    } 
  • Número de caracteres esperado: O JSON final pode ter até 10.000 caracteres, dependendo do número e complexidade das transações.

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

  • 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 Preparação de Parâmetros de Consulta.

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

Ao concluir sua execução, esse agente aciona o Agente de Preparação de Parâmetros de Consulta.

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

2.1 Tarefa do Agente

Construir parâmetros prontos para consultas a bases internas de dados com base no payload normalizado.

2.2 Prompt ou Instruções do Agente
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo normalized_transactions, reference_keys e validation_summary do agente anterior.

# 2. Objetivo
Construir parâmetros prontos para consultas a bases internas de dados.

# 3. Regras que você deve seguir para gerar sua resposta
- Inclua apenas chaves deduplicadas em cada subconsulta.
- Para calendários, derive países a partir de currency e do mercado/venue quando disponível; inclua pares relevantes.
- Para cutoffs, gere combinação [settlement_system, currency, market] deduplicada.
- Para contas, derive custodiante pretendido a partir do BIC/conta quando possível.
- Se nenhum item requerer dado de um tipo, omita a subconsulta correspondente.
- Produza estrutura que possa ser executada diretamente pelo executor de consultas (tabelas/alvos e filtros explícitos). 
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 os dados normalizados e validados 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 até 10.000 caracteres.

2.3.2 Especificação do Output

  • Formato de output: O output deve ser um objeto JSON contendo db_query_params com listas de chaves para dados estáticos, calendários, horários de cutoff, regras operacionais e pedidos de FX rates.
  • Exemplo de Estrutura de Output:
     {
      "db_query_params": {
        "static_data_keys": [...],
        "calendar_keys": [...],
        "cutoff_keys": [...],
        "product_rule_keys": [...],
        "fx_rate_requests": [...]
      }
    } 
  • Número de caracteres esperado: O JSON gerado pode ter até 5.000 caracteres.

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: Não utiliza.

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 Execução de Consultas em Banco de Dados.

2.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 3. Agente de Execução de Consultas em Banco de Dados

3.1 Tarefa do Agente

Realizar conexão com banco de dados corporativos para obter dados estáticos de clientes/contrapartes, calendários, horários de cutoff, regras operacionais e taxas de câmbio internas.

3.2 Prompt ou Instruções do Agente
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo db_query_params prontos para execução.

# 2. Objetivo
Obter dados estáticos de clientes/contrapartes, calendários, horários de cutoff, regras operacionais e taxas de câmbio internas.

# 3. Regras que você deve seguir para gerar sua resposta
- Execute consultas em bases de dados internas usando os parâmetros fornecidos.
- Retorne os resultados em um objeto JSON estruturado com datasets recuperados: static_data, calendars, cutoffs, product_rules, fx_rates (quando solicitado).
- Garanta que todas as chaves de consulta sejam atendidas ou retorne erro específico no campo correspondente. 
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 os parâmetros de consulta gerados 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 até 5.000 caracteres.

3.3.2 Especificação do Output

  • Formato de output: O output deve ser um objeto JSON contendo db_query_results com datasets recuperados: static_data, calendars, cutoffs, product_rules, fx_rates.
  • Exemplo de Estrutura de Output:
     {
      "db_query_results": {
        "static_data": [...],
        "calendars": [...],
        "cutoffs": [...],
        "product_rules": [...],
        "fx_rates": [...]
      }
    } 
  • Número de caracteres esperado: O JSON gerado pode ter até 10.000 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: Não utiliza.
  • Busca Online: Não utiliza.
  • Sistemas Externos: Se conecta a sistemas de banco de dados internos para execução de consultas.

3.3.5 Memória

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

Ao concluir sua execução, esse agente aciona o Agente de Preparação de Chamadas de Verificação Externa.

RF 4. Agente de Preparação de Chamadas de Verificação Externa

4.1 Tarefa do Agente

Preparar chamadas para serviços externos de conformidade (sanções/AML/KYC) e validações de rede conforme flags do payload.

4.2 Prompt ou Instruções do Agente
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo normalized_transactions, validation_summary e db_query_results.

# 2. Objetivo
Preparar chamadas para serviços externos de conformidade e validações de rede.

# 3. Regras que você deve seguir para gerar sua resposta
- Gere chamadas apenas para transações que possuam requires_aml_screening=true ou dados de conta/bic inconclusivos nas regras internas.
- Consolide múltiplas transações da mesma contraparte em uma única chamada de screening quando possível.
- Inclua metadados mínimos: transaction_ids vinculados, finalidade (liquidação), montante agregado por parte/moeda.
- Não inclua dados pessoais sensíveis além do estritamente necessário (id regulatório, nome legal, país). 
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 os dados normalizados e os resultados das consultas em banco de dados.
  • 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é 15.000 caracteres.

4.3.2 Especificação do Output

  • Formato de output: O output deve ser um objeto JSON contendo api_calls com lista de endpoints e payloads prontos para sanções/AML/KYC e validações de rede.
  • Exemplo de Estrutura de Output:
     {
      "api_calls": {
        "aml_screening": [...],
        "kyc_validations": [...],
        "network_validations": [...]
      }
    } 
  • Número de caracteres esperado: O JSON gerado pode ter até 8.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: Não utiliza.
  • Busca Online: Não utiliza.
  • Sistemas Externos: Não utiliza.

4.3.5 Memória

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

Ao concluir sua execução, esse agente aciona o Agente de Execução de Chamada à API (Conformidade Externa).

RF 5. Agente de Execução de Chamada à API (Conformidade Externa)

5.1 Tarefa do Agente

Executar chamadas às APIs de conformidade e diretórios externos conforme parâmetros preparados.

5.2 Prompt ou Instruções do Agente
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo api_calls prontos contendo endpoints e payloads.

# 2. Objetivo
Executar chamadas às APIs de conformidade e diretórios externos.

# 3. Regras que você deve seguir para gerar sua resposta
- Execute as chamadas em todos os endpoints listados, usando os payloads fornecidos.
- Registre o status de cada chamada e as respostas recebidas em um objeto JSON estruturado.
- Em caso de falha, capture o erro e inclua detalhes no campo correspondente para análise posterior. 
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).
  • Tipo do input: Este agente deve ser apto a receber como input os parâmetros de chamada à API preparados 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 até 8.000 caracteres.

5.3.2 Especificação do Output

  • Formato de output: O output deve ser um objeto JSON contendo external_checks_results com respostas brutas e status de cada chamada.
  • Exemplo de Estrutura de Output:
     {
      "external_checks_results": {
        "aml_responses": [...],
        "kyc_responses": [...],
        "network_responses": [...]
      }
    } 
  • Número de caracteres esperado: O JSON gerado pode ter até 12.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: Não utiliza.
  • Busca Online: Não utiliza.
  • Sistemas Externos: O agente deverá conectar-se a APIs externas para execução das chamadas.

5.3.5 Memória

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

Ao concluir sua execução, esse agente aciona o Agente de Conformidade e Decisão de Roteamento de Liquidação.

RF 6. Agente de Conformidade e Decisão de Roteamento de Liquidação

6.1 Tarefa do Agente

Aplicar regras regulatórias e operacionais para decidir se liquida, retém ou rejeita; definir roteamento (sistema/venue), modalidade (gross/net, DvP/Franco) e pré-requisitos.

6.2 Prompt ou Instruções do Agente
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo normalized_transactions, validation_summary, db_query_results e external_checks_results.

# 2. Objetivo
Aplicar regras regulatórias e operacionais para decidir se liquida, retém ou rejeita; definir roteamento e modalidade.

# 3. Regras que você deve seguir para gerar sua resposta
- Rejeite se houver: parte em lista de sanções confirmada; dados bancários inválidos irrecuperáveis; instrumento/mercado fora de escopo regulatório da entidade; moeda não suportada pelo sistema alvo.
- Coloque em hold se: screening pendente; KYC desatualizado; cutoff_risk=true e roteamento exige janelas já expiradas mas há alternativa no próximo dia útil; discrepância de quantidade/ISIN para DvP sem confirmação.
- Aprove com condições quando: netting possível e reduz risco operacional; DvP disponível e custódia confirmada.
- Ajuste settlement_date para próximo dia útil considerando calendários de ambas as pontas (pagador/recebedor) e do sistema escolhido.
- Netting: se group_key válido e soma resultante ≠ 0, crie instrução líquida; preserve referência às transações originais no campo constituents.
- DvP: exija presença de ISIN/CUSP e conta custódia válida; para Free of Payment exija justificativa regulatória no campo rationale.
- Defina motivo padronizado de hold/reject usando código e descrição. 
6.3 Configurações do Agente

6.3.1 Especificação do Input

  • Mecanismo de Acionamento: Este agente deve ser acionado automaticamente após a conclusão do agente anterior (RF 5).
  • Tipo do input: Este agente deve ser apto a receber como input os dados normalizados, resultados das consultas em banco de dados e resultados das verificações externas.
  • 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é 20.000 caracteres.

6.3.2 Especificação do Output

  • Formato de output: O output deve ser um objeto JSON contendo settlement_decisions por transação: status_proposto, motivos padronizados, roteamento, modalidade, group_key de netting, requisitos prévios e campos calculados.
  • Exemplo de Estrutura de Output:
     {
      "settlement_decisions": {
        "transaction_id": {
          "status_proposto": "approve",
          "motivos_padronizados": "",
          "roteamento": "",
          "modalidade": "",
          "group_key": "",
          "requisitos_previos": "",
          "campos_calculados": ""
        }
      }
    } 
  • Número de caracteres esperado: O JSON gerado pode ter até 15.000 caracteres.

6.3.3 Parâmetros de Geração

  • Modelo: GPT-5
  • Temperatura: 0.6

6.3.4 Ferramentas do Agente

  • Documentos: Não consulta.
  • Calculadora: Não utiliza.
  • Busca Online: Não utiliza.
  • Sistemas Externos: Não utiliza.

6.3.5 Memória

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

Ao concluir sua execução, esse agente aciona o Agente de Geração de Mensagens e Payloads de Liquidação.

RF 7. Agente de Geração de Mensagens e Payloads de Liquidação

7.1 Tarefa do Agente

Gerar instruções de liquidação em formatos requeridos e payloads para sistemas internos.

7.2 Prompt ou Instruções do Agente
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo settlement_decisions e dados de apoio de db_query_results.

# 2. Objetivo
Gerar instruções de liquidação em formatos requeridos e payloads para sistemas internos.

# 3. Regras que você deve seguir para gerar sua resposta
- Para pagamentos gross: pacs.009 (MT202COV equivalente) quando coberturas necessárias; pacs.008 para cliente final; defina instruções de cobrança/ben conforme cenário.
- Para títulos DvP: gerar secl.023/054 conforme fluxo; incluir place of settlement (PSET) com BIC do depositário.
- Popular campos obrigatórios com dados normalizados e validados: BICs, contas, moeda, valor, data valor, finalidade.
- Preencher instruções de prioridade/horário, respeitando cutoffs do sistema/rota selecionada.
- Inserir referências: instrução_id única, transaction_ids relacionadas, group_key para netting.
- Validar comprimento e conjunto de caracteres por campo antes de emissão; se falhar, mova a instrução para hold com motivo FORMAT_INVALID. 
7.3 Configurações do Agente

7.3.1 Especificação do Input

  • Mecanismo de Acionamento: Este agente deve ser acionado automaticamente após a conclusão do agente anterior (RF 6).
  • Tipo do input: Este agente deve ser apto a receber como input as decisões de liquidação e dados de apoio das consultas em banco de dados.
  • 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é 15.000 caracteres.

7.3.2 Especificação do Output

  • Formato de output: O output deve ser um objeto JSON contendo messages_to_send com array de mensagens/payloads por instrução com metadados.
  • Exemplo de Estrutura de Output:
     {
      "messages_to_send": [
        {
          "formato": "pacs.009",
          "destino": "TARGET2",
          "conteudo": {...}
        }
      ]
    } 
  • Número de caracteres esperado: O JSON gerado pode ter até 10.000 caracteres.

7.3.3 Parâmetros de Geração

  • Modelo: GPT-5
  • Temperatura: 0.6

7.3.4 Ferramentas do Agente

  • Documentos: Não consulta.
  • Calculadora: Não utiliza.
  • Busca Online: Não utiliza.
  • Sistemas Externos: Não utiliza.

7.3.5 Memória

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

Ao concluir sua execução, esse agente aciona o Agente de Execução de Chamada à API (Envio de Instruções).

RF 8. Agente de Execução de Chamada à API (Envio de Instruções)

8.1 Tarefa do Agente

Enviar mensagens/payloads gerados aos sistemas de liquidação ou mensageria designados e retornar protocolos/acknowledgements.

8.2 Prompt ou Instruções do Agente
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo messages_to_send prontos com destinos, formatos e conteúdos.

# 2. Objetivo
Enviar mensagens/payloads gerados aos sistemas de liquidação ou mensageria designados e retornar protocolos/acknowledgements.

# 3. Regras que você deve seguir para gerar sua resposta
- Envie cada mensagem para o destino designado usando o formato especificado.
- Capture e registre os protocolos/acknowledgements recebidos em um objeto JSON estruturado.
- Em caso de falha, registre o erro no campo correspondente para análise posterior. 
8.3 Configurações do Agente

8.3.1 Especificação do Input

  • Mecanismo de Acionamento: Este agente deve ser acionado automaticamente após a conclusão do agente anterior (RF 7).
  • Tipo do input: Este agente deve ser apto a receber como input as mensagens e payloads gerados 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 até 10.000 caracteres.

8.3.2 Especificação do Output

  • Formato de output: O output deve ser um objeto JSON contendo delivery_results com status de envio por mensagem, ids/protocolos retornados e erros de transporte/camada de aplicação.
  • Exemplo de Estrutura de Output:
     {
      "delivery_results": [
        {
          "status": "accepted",
          "id": "123456",
          "erro": ""
        }
      ]
    } 
  • Número de caracteres esperado: O JSON gerado pode ter até 8.000 caracteres.

8.3.3 Parâmetros de Geração

  • Modelo: GPT-5
  • Temperatura: 0.6

8.3.4 Ferramentas do Agente

  • Documentos: Não consulta.
  • Calculadora: Não utiliza.
  • Busca Online: Não utiliza.
  • Sistemas Externos: O agente deverá conectar-se a sistemas externos de liquidação/mensageria para envio das mensagens.

8.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 Reconciliação e Confirmação Inicial.

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

Ao concluir sua execução, esse agente aciona o Agente de Reconciliação e Confirmação Inicial.

RF 9. Agente de Reconciliação e Confirmação Inicial

9.1 Tarefa do Agente

Conciliar respostas de aceite/erro de sistemas de destino com as instruções emitidas, atualizando o status operacional de cada transação.

9.2 Prompt ou Instruções do Agente
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo settlement_decisions, messages_to_send e delivery_results.

# 2. Objetivo
Conciliar respostas de aceite/erro de sistemas de destino com as instruções emitidas, atualizando o status operacional de cada transação.

# 3. Regras que você deve seguir para gerar sua resposta
- Mapear códigos específicos do sistema para taxonomia interna.
- Em rejeições por dados, retornar para hold com motivo detalhado e indicar campo problemático.
- Em aceites parciais de netting, propagar impacto às transações constituintes.
- Gerar próxima ação recomendada por motivo. 
9.3 Configurações do Agente

9.3.1 Especificação do Input

  • Mecanismo de Acionamento: Este agente deve ser acionado automaticamente após a conclusão do agente anterior (RF 8).
  • Tipo do input: Este agente deve ser apto a receber como input as decisões de liquidação, mensagens enviadas e resultados de entrega.
  • 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é 20.000 caracteres.

9.3.2 Especificação do Output

  • Formato de output: O output deve ser um objeto JSON contendo settlement_status atualizado por transação/instrução: estado, códigos de erro mapeados e próximos passos sugeridos.
  • Exemplo de Estrutura de Output:
     {
      "settlement_status": {
        "transaction_id": {
          "estado": "aceito",
          "codigo_erro": "",
          "proximos_passos": ""
        }
      }
    } 
  • Número de caracteres esperado: O JSON gerado pode ter até 10.000 caracteres.

9.3.3 Parâmetros de Geração

  • Modelo: GPT-5
  • Temperatura: 0.6

9.3.4 Ferramentas do Agente

  • Documentos: Não consulta.
  • Calculadora: Não utiliza.
  • Busca Online: Não utiliza.
  • Sistemas Externos: Não utiliza.

9.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 Documentação e Trilha de Auditoria.

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

Ao concluir sua execução, esse agente aciona o Agente de Documentação e Trilha de Auditoria.

RF 10. Agente de Documentação e Trilha de Auditoria

10.1 Tarefa do Agente

Produzir documentação automática e rastreável de ponta a ponta da liquidação para cada transação/instrução.

10.2 Prompt ou Instruções do Agente
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo normalized_transactions, validation_summary, db_query_results, external_checks_results, settlement_decisions, messages_to_send e settlement_status.

# 2. Objetivo
Produzir documentação automática e rastreável de ponta a ponta da liquidação para cada transação/instrução.

# 3. Regras que você deve seguir para gerar sua resposta
- Inclua carimbo de tempo UTC e timezone local quando disponível para cada evento.
- Registre versões de regras/tabelas usadas.
- Vincule evidências externas por id/protocolo, sem armazenar dados sensíveis completos; guarde hashes/refs.
- Para cada decisão hold/reject, inclua motivo padronizado e texto curto de justificativa.
- Gere índice de busca por transaction_id e instruction_id; inclua relacionamentos constituents para lotes/netting.
- Defina campo padronizacao_realizada="sim" quando todos os artefatos requeridos estiverem presentes; caso contrário "nao" com lista de pendências. 
10.3 Configurações do Agente

10.3.1 Especificação do Input

  • Mecanismo de Acionamento: Este agente deve ser acionado automaticamente após a conclusão do agente anterior (RF 9).
  • Tipo do input: Este agente deve ser apto a receber como input todos os artefatos gerados anteriormente no fluxo.
  • 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é 30.000 caracteres.

10.3.2 Especificação do Output

  • Formato de output: O output deve ser um objeto JSON contendo audit_package por transação com: resumo executivo, eventos em ordem temporal, regras aplicadas, decisões e justificativas, dados de evidência e status final.
  • Exemplo de Estrutura de Output:
     {
      "audit_package": {
        "transaction_id": {
          "resumo_executivo": "",
          "eventos": [...],
          "regras_aplicadas": [...],
          "decisoes": [...],
          "dados_de_evidencia": [...],
          "status_final": ""
        }
      }
    } 
  • Número de caracteres esperado: O JSON gerado pode ter até 20.000 caracteres.

10.3.3 Parâmetros de Geração

  • Modelo: GPT-5
  • Temperatura: 0.6

10.3.4 Ferramentas do Agente

  • Documentos: Não consulta.
  • Calculadora: Não utiliza.
  • Busca Online: Não utiliza.
  • Sistemas Externos: Não utiliza.

10.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 fecha o fluxo e deve ser armazenada para auditoria.

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

A execução deste agente finaliza o fluxo. O pacote de auditoria gerado é o resultado que deve ser disponibilizado para auditoria e compliance.

© 2025 prototipe.ai. Todos os direitos reservados.