Pular para o conteúdo

apps/security/bank-transaction-audit

145 · Segurança & Auditoria · ≈ 6 min de estudo

Transação Bancária com Auditoria

Cada movimentação de dinheiro deixa um registro imutável na trilha da conta: quem iniciou, de qual IP e canal, o valor e o saldo antes e depois — inclusive das tentativas recusadas. Cada conta tem a própria cadeia de hashes, e a verificação confere a cadeia e reconcilia a soma dos movimentos auditados com o saldo atual. Use para reconstruir o histórico de uma conta diante do regulador ou de uma disputa.

passos
6
arquivos
6
testes
0
tecnologias
4
Infraestrutura realTypeScriptBunPostgreSQLDocker
Baixar cartão

Cenário

Um banco digital move dinheiro por PIX entre contas de clientes. Cada PIX liquidado gera um débito na trilha da origem e um crédito na do destino, com o mesmo transfer_id. Um PIX sem saldo é recusado e mesmo assim auditado. A verificação pega dois tipos de fraude: um registro reescrito por quem desativou a RULE (a cadeia quebra no seq exato) e um saldo alterado por fora do fluxo (a cadeia está íntegra, mas a soma auditada não fecha com o saldo).

Planta

Sequência
8/8
PIX 0001-1 → 0002-9 R$ 500,001BEGIN, FOR UPDATE nas duas contas em ordem de id2debita e credita, COMMIT3pix.debited na cadeia da 0001-14pix.credited na cadeia da 0002-95PIX sem saldo6ROLLBACK7pix.declined, insufficient_funds8ClientepixTransferaccountsaudit_movements
8

8 passos — reproduza para seguir o fluxo

Como funciona

6 passos

Cada transferência deixa trilha auditável.

Esconde cada passo: lembre antes de tocar para revelar.

  1. 01

    balancesMove trava as duas contas em ordem de id, confere o saldo em centavos e dá commit

  2. 02

    Depois do commit, movementAudit grava o débito e o crédito, cada um na cadeia da sua conta

  3. 03

    Recusa por saldo insuficiente faz rollback do negócio e grava pix.declined com o motivo — o rollback não apaga a tentativa

  4. 04

    Cada conta tem a cabeça da cadeia em audit_heads: a trava é por conta, então contas diferentes são auditadas em paralelo

  5. 05

    accountVerify recalcula a cadeia da conta e reconcilia saldo de abertura + soma dos movimentos com o saldo atual

  6. 06

    CREATE RULE ... DO INSTEAD NOTHING transforma UPDATE e DELETE na trilha em nada

Trade-offs

O que se ganha, o que se paga

4 vantagenscada ganho tem um preço4 custos

Vantagens

  • Tentativas recusadas também ficam na trilha

  • Cadeia por conta não serializa o banco inteiro

  • Reconciliação pega saldo alterado por fora do fluxo

  • RULE barra UPDATE e DELETE sem depender de trigger

Custos

  • Falha entre o commit e o append deixa movimento sem registro — a reconciliação acusa

  • Verificar a instituição inteira exige percorrer todas as cadeias

  • A ordem na trilha pode diferir da ordem de commit entre PIX concorrentes

  • TRUNCATE ignora RULE: revogue o privilégio do papel da aplicação

apps/security/bank-transaction-audit

6 arquivos

src/

  • transfer_pix.tsPIX com trava em ordem, commit e auditoria de débito, crédito ou recusa
  • audit_chain.tsAppend na cadeia da conta e verificação com reconciliação do saldo
  • audit_hash.tsHash do movimento e efeito dele no saldo
  • config_audit.tsConfiguração validada do ambiente
  • demo.tsdemoPIX liquidados, recusa auditada, verificação e adulteração

sql/

  • 01_schema.sqlschemaContas, cabeças das cadeias e trilha com RULEs

Executar · com Docker

  1. ./docker.sh up# sobe PostgreSQL
  2. cp .env.example .env# variáveis de ambiente
  3. bun install# dependências
  4. bun run demo# roda o cenário
  5. bun run test# integração contra o serviço real
Requisitos
BunDocker
Sobe junto
PostgreSQL

Por que se relacionam

Teste rápido

Qual destes combina com Transação Bancária com Auditoria?

Próximo projeto · Segurança & AuditoriaAudit Log
Esc

↑ ↓ navegarEnter abrir191 resultados