Banco por Dentro (1/3): como um banco funciona, visão de negócio e o elevador de arquitetura

Imagine que você construiu um sistema de cache distribuído. Você tem nós que guardam dados temporariamente para outros nós que precisam deles. O banco funciona de forma análoga, mas com dinheiro e com uma dimensão de tempo: ele guarda o dinheiro de quem tem (os depositantes) e o disponibiliza para quem precisa agora (os tomadores de crédito). Essa operação tem nome: intermediação financeira.

A diferença crítica para o engenheiro entender é que o banco não guarda o seu dinheiro num cofre esperando você pedir de volta. Ele o empresta para outra pessoa. Quando você deposita R$ 1.000, o banco registra uma obrigação com você (ele te deve R$ 1.000 + juros) e ao mesmo tempo cria um ativo emprestando esse dinheiro para um tomador a uma taxa maior. A diferença entre a taxa que ele cobra do tomador e a taxa que ele paga a você é o spread bancário: a margem bruta do produto principal.

Em termos de engenharia: o banco é um sistema de transformação de risco e tempo. Ele pega recursos de curto prazo (depósitos que você pode sacar amanhã) e os transforma em recursos de longo prazo (empréstimos de 36 meses). Isso cria um risco estrutural chamado descasamento de prazos: e gerenciar esse risco é uma das razões pelas quais o BACEN exige capital mínimo e reservas compulsórias. Sem regulação, esse sistema colapsa facilmente (como vimos em 2008 nos EUA).

O produto do banco, portanto, não é o dinheiro em si, o dinheiro é a matéria-prima. O produto é a confiança intermediada: a certeza de que você pode depositar hoje e sacar amanhã, e de que o tomador receberá o crédito prometido. Toda a arquitetura tecnológica de um banco existe para sustentar essa confiança em escala.

Gregor Hohpe descreve o arquiteto de software moderno como alguém que não fica preso num único andar. Ele sobe ao andar executivo (onde vivem estratégia, regulação e produto) e desce ao andar técnico (onde vivem código, infraestrutura e dados), traduzindo a linguagem de um para o outro. Num banco, essa habilidade não é opcional, é o requisito número um.

Por quê? Porque decisões de negócio num banco têm consequências técnicas imediatas e vice-versa. Exemplo: o BACEN decide que o Pix deve liquidar em até 10 segundos, 24 horas por dia, 365 dias por ano. Isso não é uma feature request, é uma restrição regulatória com multa. O arquiteto que entende apenas o andar técnico vai desenhar um sistema de mensageria assíncrona excelente, mas vai errar o SLA. O arquiteto que entende apenas o negócio vai prometer o SLA sem saber que o sistema legado de ledger tem uma janela de manutenção às 2h da manhã.

O elevador de Hohpe, aplicado a bancos, tem pelo menos quatro andares:

1. Andar regulatório: BACEN, CMN, CVM, COAF. As regras que não são negociáveis.
2. Andar de negócio: produtos, receitas, clientes, risco de crédito, spread.
3. Andar de capacidades: o que o banco sabe fazer: processar pagamentos, conceder crédito, emitir cartões.
4. Andar técnico: sistemas, APIs, bancos de dados, filas, infraestrutura.

Esta primeira aula cobre os andares 1, 2 e 3. A Parte 2 aprofunda o andar regulatório com os trilhos do SPB. A Parte 3 desce ao andar técnico com arquitetura de sistemas. Meu conselho para quem está migrando: não pule para o andar técnico antes de entender os andares de cima. Você vai construir a solução certa para o problema errado.

Um mapa de capacidades de negócio é diferente de um organograma. Ele descreve o que a organização sabe fazer, independente de como está estruturada internamente. Para um engenheiro, pense nisso como as interfaces públicas de um sistema, o que ele expõe, não como está implementado.

Um banco comercial típico no Brasil tem as seguintes capacidades de negócio:

• Conta corrente e poupança: abertura, manutenção, saldo, extrato. É o ponto de entrada do cliente. Sem conta, não há relacionamento.
• Crédito: análise, concessão, gestão e cobrança de empréstimos, financiamentos e linhas de crédito. É onde o banco gera a maior parte da receita (spread).
• Cartões: emissão de cartões de débito e crédito, processamento de transações, faturamento, cobrança. Pode ser próprio ou via parceria com bandeiras (Visa, Mastercard).
• Pagamentos: execução de Pix, TED, DOC, boletos, débito automático. É o motor de movimentação de dinheiro.
• Tesouraria: gestão da liquidez do próprio banco, compra e venda de títulos públicos e privados, hedge cambial. O banco também investe para si.
• Câmbio: compra e venda de moeda estrangeira para clientes e para a própria posição do banco.
• Investimentos: distribuição de produtos de investimento (CDB, LCI, fundos, ações) para clientes.
• Garantias e avais: o banco garante obrigações de terceiros (ex.: carta de crédito para importação).
• Recuperação e cobrança: gestão de créditos inadimplentes, negociação, venda de carteiras para fundos de recuperação.
• Compliance e PLD: monitoramento de operações suspeitas, KYC (conheça seu cliente), reporte ao COAF.
• Risco: gestão de risco de crédito, mercado, liquidez e operacional. Obrigação regulatória (Basileia III).
• Políticas e limites: definição e enforcement de limites operacionais (ex.: limite de Pix por cliente, limite de crédito).

Cada uma dessas capacidades será, no andar técnico (Parte 3), implementada por um ou mais sistemas. O erro clássico do engenheiro que chega num banco é tentar mapear sistemas antes de entender capacidades.

Antes de ver qualquer diagrama de sistema, você precisa internalizar seis conceitos que aparecem em toda conversa técnica num banco. São os 'tipos primitivos' do domínio financeiro.

1. Ledger (Livro-Razão): É o registro contábil central. Cada movimentação de dinheiro, depósito, saque, pagamento, estorno, é gravada como um par de lançamentos: um débito (saída de valor de uma conta) e um crédito (entrada de valor em outra conta). Isso é a contabilidade de partidas dobradas, inventada no século XV. O ledger é o 'banco de dados de verdade' do banco. Se o ledger diz que você tem R$ 1.000, você tem R$ 1.000, independente do que qualquer outro sistema mostre. Em sistemas modernos, o ledger é frequentemente um serviço separado, imutável, append-only.

2. Conta: Uma conta é um identificador que agrega lançamentos no ledger. Não confunda com 'conta corrente do cliente', essa é apenas um tipo. Existem contas de clientes, contas de receita, contas de provisão, contas de reserva. Pense numa conta como uma Map<String, List<Lançamento>> onde a chave é o identificador da conta.

3. Limite: Um limite é uma restrição sobre quanto pode ser movimentado em uma conta ou operação. Limite de crédito, limite diário de Pix, limite de saque. É um parâmetro de política, não um saldo. Confundir limite com saldo é um bug clássico de quem chega do mundo de e-commerce.

4. Liquidação (Settlement): O momento em que a obrigação financeira se torna definitiva e irrevogável entre instituições. Antes da liquidação, uma transação é apenas uma intenção. Depois da liquidação, é um fato contábil. No Pix, a liquidação acontece em segundos via SPI. No cartão de crédito, pode levar dias.

5. Boletador: O sistema que gera e registra boletos bancários. Um boleto tem um código de barras, uma data de vencimento, um valor, e está registrado numa câmara de compensação (CIP). Quando o pagador paga, o sistema de compensação notifica o banco do beneficiário para creditar a conta.

6. Carteira (Portfolio): O conjunto de contratos de crédito ativos. Cada contrato tem um saldo devedor, uma taxa de juros, um prazo, e um status (normal, atrasado, em cobrança, baixado). A 'saúde' da carteira é medida pela inadimplência (% do saldo em atraso) e pela provisão (quanto o banco reservou para cobrir perdas esperadas).

Para um engenheiro, o banco pode ser modelado como um sistema de filas com dois tipos de eventos: entradas e saídas. Cada evento tem origem, destino, valor, e precisa ser liquidado e registrado no ledger.

Entradas (dinheiro chegando ao banco):

• Depósito em espécie: cliente vai à agência ou caixa eletrônico, entrega cédulas. O caixa registra um crédito na conta do cliente e um débito na conta de caixa.
• Pix recebido: outra instituição envia uma mensagem ao SPI (Sistema de Pagamentos Instantâneos). O BACEN debita a conta de reservas do banco remetente e credita a do banco destinatário. O banco destinatário então credita a conta do cliente.
• TED recebida: similar ao Pix, mas via STR (Sistema de Transferência de Reservas), em horário comercial.
• Crédito de salário (DOC/TED): empresa envia arquivo de crédito em lote para o banco, que distribui para as contas dos funcionários.
• Pagamento de boleto: cliente de outro banco paga um boleto emitido pelo seu banco. A câmara de compensação (CIP) processa e notifica o banco para creditar o beneficiário.

Saídas (dinheiro saindo do banco):

• Saque: cliente retira espécie. Débito na conta do cliente, crédito na conta de caixa (que depois é reposta).
• Pix enviado: cliente instrui o banco a enviar dinheiro. O banco verifica saldo e limite, envia mensagem ao SPI, BACEN debita reservas do banco e credita o destinatário.
• Pagamento de conta (boleto/débito automático): débito na conta do cliente, crédito na câmara de compensação, que repassa ao beneficiário.
• Compra no cartão de débito: autorização imediata, débito na conta do cliente, crédito na conta de liquidação do banco, que depois repassa ao lojista via bandeira.

O ponto crítico: toda saída precisa de saldo disponível ou limite aprovado. E toda movimentação, entrada ou saída, precisa de um lançamento correspondente no ledger. Sem isso, o banco não fecha o balanço.

Se você olhar o Diagrama 3 com cuidado, vai notar que o ledger aparece em dois lugares: no banco remetente (passo 4) e no banco destinatário (passo 10). Isso não é acidente, é a arquitetura fundamental. Todo evento financeiro que tem consequência real precisa ser registrado no ledger. Sem esse registro, o banco não sabe quanto deve aos clientes, quanto os clientes devem a ele, e não consegue fechar o balanço contábil exigido pelo BACEN.

O ledger é, portanto, o sistema mais crítico de um banco, mais crítico que o app, mais crítico que o site, mais crítico que o CRM. Se o app cair, o cliente fica sem acesso. Se o ledger corromper um lançamento, o banco tem um problema regulatório, legal e de confiança ao mesmo tempo.

Isso explica alguns comportamentos que parecem estranhos para quem vem do mundo de startups:

• Janelas de manutenção: sistemas de ledger legados (mainframe COBOL, por exemplo) precisam de janelas para processar fechamentos diários. Isso é real e ainda acontece em 2024 em muitos bancos brasileiros.
• Resistência a mudanças no schema: um campo novo no ledger pode quebrar décadas de relatórios regulatórios. Cada mudança é uma operação de risco.
• Dupla validação e reconciliação: bancos têm processos de reconciliação que comparam o ledger interno com os extratos do BACEN. Qualquer diferença é um incidente.

Para o arquiteto que está chegando: entenda o ledger antes de propor qualquer mudança de sistema. Saiba quem o opera, qual a tecnologia, quais os horários de fechamento, e quais os processos de reconciliação. Esse é o mapa do campo minado.