Event Sourcing Bancário: Arquitetura CRM e Audit Trail

No panorama Fintech de 2026, a gestão de dados já não diz respeito apenas à conservação do estado atual, mas à capacidade de demonstrar matematicamente como se chegou a esse estado. O event sourcing bancário representa a mudança de paradigma necessária para responder às rigorosas normas de compliance (como a PSD3 e as evoluções de Basileia) e às exigências de transparência operacional. Neste guia técnico, exploraremos por que razão a arquitetura CRUD (Create, Read, Update, Delete) está agora obsoleta para os CRM financeiros críticos e como implementar um sistema baseado em eventos imutáveis para a gestão de processos de crédito habitação.

O Problema do CRUD no Setor Financeiro

Durante décadas, o desenvolvimento de software baseou-se no modelo CRUD. Numa base de dados relacional clássica, quando um processo de crédito passa de “Em Análise” para “Aprovado”, executamos um comando UPDATE que sobrescreve o valor anterior. Embora eficiente para o armazenamento, esta abordagem acarreta uma perda de informação crítica: perde-se a história.

Num contexto bancário, sobrescrever dados é um risco inaceitável. Para garantir o audit trail, os programadores recorrem frequentemente a tabelas de log separadas ou triggers de base de dados complexos. No entanto, esta abordagem apresenta dois defeitos fatais:

• Desalinhamento: O log é um efeito colateral, não a fonte da verdade. Se o log falhar mas o update for bem-sucedido, ocorre uma corrupção da auditoria.
• Falta de contexto: Sabemos que o dado foi alterado, mas muitas vezes perdemos o “porquê” (a intenção de negócio).

Event Sourcing: O Processo como História, não como Estado

O event sourcing bancário inverte este modelo. Em vez de memorizar o estado atual de um processo de crédito, memorizamos a sequência de eventos que conduziram a tal estado. A base de dados já não contém uma linha modificável, mas um append-only log (registo de apenas adição) imutável.

Segundo os princípios definidos por peritos como Martin Fowler, o estado atual da aplicação é puramente uma derivação matemática: é a soma de todos os eventos passados reproduzidos em sequência.

Modelação do Domínio: Dos Objetos aos Eventos

Imaginemos o ciclo de vida de um crédito habitação. Num sistema CRUD teríamos uma tabela Processos. Em Event Sourcing, definimos eventos de domínio precisos:

• ProcessoCreditoCriado (Contém ID cliente, montante solicitado, data)
• DocumentacaoRendimentoCarregada (Contém referências aos PDF, metadados)
• ScoringCreditoCalculado (Contém a pontuação da Central de Responsabilidades no momento do cálculo)
• TaxaJuroBloqueada (Contém a taxa IRS do dia)
• AprovacaoEmitida (Contém o ID de quem aprovou)

Cada evento é um facto histórico imutável. Não pode ser apagado ou modificado, apenas compensado por um evento posterior (ex. AprovacaoAnulada).

Arquitetura de Referência: CQRS e Streaming

A implementação de um sistema de event sourcing bancário requer quase sempre a adoção do padrão CQRS (Command Query Responsibility Segregation). Dado que ler uma sequência de 100 eventos para reconstruir o estado de um processo cada vez que um operador abre o dashboard é ineficiente, separamos a escrita da leitura.

1. O Lado de Escrita (Command)

O coração do sistema é o Event Store. Tecnologias como Apache Kafka ou Amazon Kinesis são ideais para este fim devido à sua natureza de log distribuído e à persistência duradoura.

Quando um agente CRM clica em “Aprovar Rendimento”, o sistema:

1. Valida o comando em relação ao estado atual (reconstruído em memória).
2. Gera o evento RendimentoVerificado.
3. Escreve o evento num tópico Kafka (ex. credito-events-v1).

2. O Lado de Leitura (Query) – As Projeções

Para visualizar os dados no CRM, utilizamos “Consumers” que escutam o tópico Kafka e atualizam bases de dados otimizadas para a leitura (Projeções). Podemos ter diferentes projeções para o mesmo fluxo de dados:

• Projeção Operacional (SQL/NoSQL): Uma tabela ProcessosAtivos em PostgreSQL ou MongoDB que contém o estado atual para a UI do agente.
• Projeção Analítica (Elasticsearch): Um índice para permitir à equipa de marketing pesquisar “todos os processos recusados por rendimento insuficiente no último mês”.
• Projeção Audit (Cold Storage): Arquivo em S3/Glacier para compliance a longo prazo.

Vantagens Críticas para a Fintech

Audit Trail Nativo e «By Design»

No event sourcing, o audit trail não é uma funcionalidade adicional: é a própria base de dados. Não é possível modificar o estado sem deixar um rasto indelével. Isto satisfaz nativamente os requisitos de não repúdio exigidos pelos órgãos de supervisão.

Time-Travel Debugging

Esta é talvez a funcionalidade mais poderosa para os programadores e auditores. Imaginem que um cliente contesta uma taxa de juro aplicada há seis meses. Num sistema CRUD, veriam apenas a taxa atual. Com o event sourcing, podem:

1. Pegar no ID do processo.
2. Reproduzir os eventos do 0 até à data exata da contestação (ex. 11/01/2025 às 14:30).
3. Ver exatamente o estado do sistema, os dados de input e as regras de negócio ativas naquele preciso instante.

Isto permite responder a perguntas como: “Por que razão o sistema recusou o processo naquele dia?” reconstruindo o contexto exato, incluindo eventuais bugs presentes no código naquela data passada.

Implementação Técnica: Snippet de um Evento

Eis como poderia parecer um evento JSON estruturado para um sistema bancário:

{
  "eventId": "550e8400-e29b-41d4-a716-446655440000",
  "eventType": "RiskAssessmentCompleted",
  "aggregateId": "CREDITO-2026-8899",
  "timestamp": "2026-01-11T10:15:30Z",
  "version": 1,
  "metadata": {
    "userId": "agente_rossi",
    "ipAddress": "192.168.1.50",
    "correlationId": "req-123-abc"
  },
  "payload": {
    "riskScore": "LOW",
    "maxLTV": 0.80,
    "interestRateSpread": 1.25,
    "rulesVersion": "v2025.12"
  }
}

Notem o campo rulesVersion no payload: historicizar também a versão das regras de negócio utilizadas é fundamental para justificar as decisões automáticas em sede de auditoria.

Desafios e Considerações Finais

Adotar o event sourcing bancário não é isento de custos. A complexidade arquitetural aumenta e requer uma gestão atenta de:

• Evolução de Esquema: Como gerir eventos criados há 5 anos com uma estrutura diferente da atual? (Solução: Upcasters).
• Snapshotting: Para processos com milhares de eventos, reproduzir tudo do zero é lento. Criam-se “snapshots” periódicos do estado para acelerar o carregamento.
• RGPD e Direito ao Esquecimento: Apagar dados num log imutável é complexo. Frequentemente recorre-se à técnica de “Crypto-shredding” (cifrar os dados sensíveis e apagar a chave de decifragem).

Apesar destes desafios, para os sistemas core banking e os CRM financeiros modernos, os benefícios em termos de segurança, rastreabilidade e resiliência superam largamente os custos de implementação. Passar ao modelo de eventos significa deixar de perder dados e começar a construir um património informativo histórico de valor inestimável.

Perguntas frequentes