Auditoria de eventos

A BlendFi mantém um registro de auditoria append-only com toda mudança de estado em recursos da plataforma: criação de usuário, mudança de KYC, criação e consumo de cotação, transição de transação, transição de conversão, processamento de webhook, ações administrativas. Cada evento é imutável e retido por anos.

Por que existe

Três forças desenham o registro de auditoria:

• Retenção regulatória. A BlendFi é regulada pelo Banco Central. A regulação determina disponibilidade de registros para o regulador por pelo menos cinco anos. O registro de auditoria é a fonte durável dessa obrigação.
• Monitoramento contínuo. A regulação exige visibilidade ininterrupta da atividade institucional. Um stream uniforme e append-only de eventos é o mecanismo que sustenta esse requisito.
• Forense e suporte. Quando um parceiro reporta que uma cotação foi consumida de forma inesperada, ou um operador precisa saber quem aprovou um KYC, o registro é a fonte autoritativa. Ele responde a pergunta canônica: quem fez o que, em qual recurso, em qual instante, e como o recurso ficou antes e depois.

O princípio de design: auditamos no ponto da decisão de negócio, não no nível do banco de dados. Cada evento representa uma decisão acontecida, não uma operação SQL. É isso que regulador, suporte e parceiro efetivamente querem ler.

O que é registrado

Toda mutação em recurso da plataforma emite um evento:

• Ciclo de vida de usuário: criação, atualização, soft-delete, início de submissão de KYC, mudança de status de KYC.
• Ciclo de vida de cotação: criação, consumo, expiração, cancelamento.
• Ciclo de vida de transação e conversão: cada transição de estado, incluindo terminais de falha.
• Processamento de webhook: cada evento externo que resultou em mudança de estado.
• Ações administrativas: overrides operacionais, resoluções, suspensões.

O que não entra nesse registro:

• Leituras (GET). A auditoria cobre mudanças de estado, não acessos.
• Tentativas de autenticação falhas. Vão para o log de segurança, não para o trail de negócio.
• Cálculos intermediários internos que não persistem estado.

O que cada evento carrega

Cada evento tem campos uniformes que tornam a leitura forense direta:

• Ator: quem realizou a ação (chave de API da organização, operador BlendFi, sistema interno, serviço externo, usuário final).
• Ação: nome estável e legível da operação, no formato recurso.evento. Exemplos: user.created, quote.consumed, conversion.completed, user.kyc_approved.
• Recurso: tipo e identificador do recurso afetado.
• Estado anterior e estado posterior: snapshot sanitizado dos campos que mudaram. Identificadores e dados sensíveis (CPF completo, segredos, chaves) ficam de fora por design.
• Contexto: request_id correlacionando ao request HTTP que originou a ação, IP e user-agent quando aplicável.
• Carimbo de tempo: instante da decisão, em UTC.

Invariantes

Estas garantias valem para todo evento. São contratuais:

• Append-only. A tabela de eventos rejeita UPDATE, DELETE e TRUNCATE, inclusive para super-usuários. Correções acontecem emitindo novos eventos que descrevem a correção, jamais mutando os anteriores.
• Toda mudança de estado em recurso emite exatamente um evento. Operações idempotentes (retentativa com mesma Idempotency-Key) não re-emitem.
• Sem PII e segredos no registro. Snapshots são sanitizados na origem. CPF nunca aparece em texto plano; segredos de webhook nunca aparecem; chaves de API nunca aparecem.
• Nomes de ação são estáveis. Fazem parte do contrato operacional. Novos nomes podem ser adicionados, nunca renomeados.

Como sua organização interage com o registro

A consulta ao registro hoje é feita pelo time da BlendFi:

• Suporte e investigação. Em chamados de suporte, o time da BlendFi consulta o registro pelo request_id ou pelo id do recurso e devolve a cronologia das transições. Se você compartilhou request_id no contato (todo erro retorna um), a investigação é direta.
• Pedidos de auditoria formal. Em casos que exijam evidência documental (auditoria interna, requisição regulatória), o time gera o relatório a partir do registro com o escopo solicitado.

Próximos passos

• Webhooks: cada evento de webhook que você recebe tem um evento correspondente no registro.
• Erros e retentativas: toda resposta de erro carrega request_id, que é a chave para localizar a sua chamada no registro.