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

Primeira aula de uma série de três para devs e arquitetos que querem migrar para o mercado financeiro. Cobre o que um banco é, por que existe, como seu dinheiro se transforma em produto, e como o arquiteto usa o 'elevador' de Gregor Hohpe para transitar entre o andar de negócio e o andar técnico. Foco no Brasil e no BACEN.

- URL: https://fernando.moretes.com/studies/banco-por-dentro-1-como-um-banco-funciona

- Markdown: https://fernando.moretes.com/studies/banco-por-dentro-1-como-um-banco-funciona/study.md?lang=pt

- Type: Guia / Deep Dive

- Domain: Mercado Financeiro

- Date: 2026-06-21

- Tags: banking, architecture-elevator, financial-services, bacen, payments, capability-map, brazil, didactic

- Reading time: 12 min

---

Se você vem do mundo de software e recebeu uma proposta para trabalhar num banco — ou numa fintech que precisa se comportar como um — provavelmente sentiu aquela sensação estranha: o vocabulário é diferente, as reuniões têm siglas que ninguém explica, e a documentação pressupõe que você já sabe o que é um 'ledger', um 'spread' ou uma 'posição de tesouraria'. Este guia existe para eliminar essa barreira. Não vou falar de sistemas ainda. Vou começar pelo andar de cima — o negócio — e descer com você pelo elevador até o chão técnico, exatamente como Gregor Hohpe descreve em 'The Software Architect Elevator'. Ao final desta primeira parte, você vai entender o que um banco faz, por que cada área existe, e como o dinheiro flui de verdade. As Partes 2 e 3 desta série cobrem, respectivamente, os trilhos de pagamento e o BACEN, e a arquitetura de sistemas de um banco moderno.

## O que você vai aprender nesta aula

- O que é intermediação financeira e por que um banco não é uma 'caixa de dinheiro'
- O conceito de spread bancário em linguagem de engenharia (margem entre custo e receita)
- Como usar o Architecture Elevator de Hohpe para navegar entre negócio e tecnologia num banco
- O mapa completo de capacidades de negócio de um banco: conta, crédito, cartões, pagamentos, tesouraria, câmbio, investimentos, compliance/PLD, risco
- Os 'motores conceituais': ledger, conta, limite, liquidação, boletador, carteira — o que cada um significa
- Como o dinheiro entra e sai de um banco (depósito, Pix, TED, saque, pagamento)

## Glossário rápido — termos que aparecem nesta aula

- **Banco / Instituição Financeira:** Empresa autorizada pelo BACEN a captar depósitos do público e conceder crédito. Pense num intermediário de confiança regulado.
- **BACEN (Banco Central do Brasil):** Regulador e supervisor do sistema financeiro nacional. Define as regras do jogo e opera a infraestrutura de pagamentos (SPB).
- **Intermediação financeira:** O banco pega dinheiro de quem tem (depositantes) e empresta para quem precisa (tomadores). É o negócio central.
- **Spread bancário:** A diferença entre a taxa que o banco cobra no empréstimo e a taxa que paga ao depositante. É a margem bruta do produto principal.
- **Ledger (Livro-Razão):** Registro contábil central onde cada movimentação de dinheiro é gravada como débito ou crédito numa conta. É o 'banco de dados de verdade' do banco.
- **Liquidação (Settlement):** O momento em que o dinheiro de fato muda de mãos entre instituições. Antes da liquidação, há apenas uma promessa.
- **Boletador:** Sistema que gera boletos bancários — documentos de cobrança usados amplamente no Brasil para pagamentos.
- **Carteira (de crédito):** O conjunto de todos os contratos de crédito ativos de um banco. Pense num array de objetos Loan com status, saldo, e risco.
- **PLD (Prevenção à Lavagem de Dinheiro):** Conjunto de controles obrigatórios para detectar e reportar operações suspeitas ao COAF.
- **SPB (Sistema de Pagamentos Brasileiro):** Infraestrutura operada pelo BACEN que conecta todas as instituições financeiras para liquidação de pagamentos no Brasil.

## O que é um banco — a analogia do engenheiro

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.

## O Architecture Elevator num banco — por que você precisa subir antes de descer

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.

## Diagrama 1 — Contexto do banco: atores e ecossistema

Quem interage com um banco e por quê. Leia de fora para dentro: os atores externos definem as obrigações; o banco orquestra; o BACEN arbitra.

### 🏛️ Reguladores

- BACEN Regulador + SPB (external)
- COAF Inteligência financeira (external)
- CVM Mercado de capitais (external)

### 👤 Clientes

- Pessoa Física Correntista / tomador (user)
- Pessoa Jurídica Empresa / parceiro (user)

### 🏦 Banco (núcleo)

- Conta Corrente + Ledger (data)
- Crédito Carteira + Limite (compute)
- Pagamentos Pix / TED / Boleto (compute)
- Cartões Emissão + Fatura (compute)
- Tesouraria Liquidez + ALM (compute)
- Compliance / PLD Monitoramento (security)

### 🌐 Infraestrutura de mercado

- SPB / SPI Sistema de pagamentos BR (external)
- Bandeiras Visa / Mastercard (external)
- B3 Bolsa / custódia (external)
- Bureaus de crédito Serasa / SPC / SCR (external)

### Fluxos

- pf -> conta: deposita / saca
- pf -> credito: solicita crédito
- pf -> pagamentos: envia Pix / paga boleto
- pj -> cartoes: aceita / emite cartão
- pagamentos -> spb: liquida via SPB/SPI
- cartoes -> bandeiras: autorização / liquidação
- tesouraria -> b3: compra/vende títulos
- credito -> bureaus: consulta score / SCR
- compliance -> coaf: reporta suspeitos
- bacen -> conta: regulação + reserva compulsória
- bacen -> spb: opera infraestrutura

## Mapa de capacidades — o que um banco sabe fazer

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.

## Diagrama 2 — Mapa de capacidades de negócio do banco

Capacidades agrupadas por domínio. Cada bloco é uma 'interface de negócio' — o que o banco sabe fazer, não como faz. O arquiteto usa este mapa para localizar onde uma decisão técnica tem impacto.

### 💰 Captação e Conta

- Conta Corrente Abertura / Saldo (data)
- Poupança / CDB Captação remunerada (data)

### 💳 Crédito e Cartões

- Crédito Análise / Concessão (compute)
- Cartões Emissão / Fatura (compute)
- Cobrança / Recuperação Inadimplência (compute)

### 🔄 Pagamentos e Transferências

- Pix Instantâneo 24/7 (messaging)
- TED / DOC Transferência D+0 (messaging)
- Boletador Emissão / Baixa (messaging)
- Débito Automático Recorrência (messaging)

### 📈 Tesouraria e Mercados

- Tesouraria Liquidez / ALM (compute)
- Câmbio FX Spot / Forward (compute)
- Investimentos Distribuição (compute)

### 🛡️ Controle e Risco

- Compliance / PLD KYC / COAF (security)
- Risco Crédito / Mercado / Liquidez (security)
- Políticas e Limites Enforcement (security)

### 📒 Núcleo Contábil

- Ledger (Razão) Debits / Credits (data)
- Liquidação Settlement Engine (data)

### Fluxos

- cap_conta -> cap_ledger: toda movimentação
- cap_credito -> cap_ledger: desembolso / parcela
- cap_pix -> cap_liquidacao: liquidação SPI
- cap_ted -> cap_liquidacao: liquidação STR
- cap_cartao -> cap_liquidacao: liquidação bandeira
- cap_politicas -> cap_credito: limite de crédito
- cap_politicas -> cap_pix: limite Pix
- cap_pld -> cap_conta: monitora operações
- cap_risco -> cap_credito: score / provisão

## Os trilhos de pagamento do banco — o que cada um é para
| Critério | Modalidade | Velocidade | Limite típico | Disponibilidade | Caso de uso principal |
| --- | --- | --- | --- | --- | --- |
| Pix | Instantâneo (≤10s) | Sem limite definido (banco define) | 24/7/365 | Transferências P2P, pagamentos a lojistas, governo | SPI (Sistema de Pagamentos Instantâneos) |
| TED | Mesmo dia (D+0) | Sem limite mínimo regulatório | Dias úteis, horário comercial | Transferências de alto valor entre bancos | STR (Sistema de Transferência de Reservas) |
| DOC | D+1 (dia seguinte) | Até R$ 4.999,99 | Dias úteis | Transferências de pequeno valor (legado, em extinção) | SILOC / STR |
| Boleto Bancário | D+1 a D+2 (compensação) | Qualquer valor | Dias úteis (pagamento aceito 24/7 em canais digitais) | Cobrança de clientes, pagamento de contas | CIP / ISPB |
| Débito Automático | D+0 (agendado) | Definido pelo contrato | Dias úteis | Recorrência: assinaturas, contas de serviço | SITRAF / STR |
| Cartão de Crédito | Autorização imediata; liquidação D+30 (fatura) | Limite de crédito do cliente | 24/7 (autorização) | Compras parceladas, e-commerce, viagens | Bandeiras (Visa/MC) + CIP |

## Os motores conceituais do banco — o vocabulário que você vai ouvir todo dia

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).

## Fluxo de dinheiro — entradas e saídas de um banco

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.

## Diagrama 3 — Fluxo ponta a ponta: um Pix saindo

Siga os números: o cliente instrui, o banco valida, o SPI liquida, o ledger registra. Cada seta é uma obrigação que precisa ser honrada em ≤10 segundos.

### 👤 Iniciador

- App / Internet Banking Cliente remetente (frontend)

### 🏦 Banco Remetente

- API Pix Validação inicial (compute)
- Motor de Políticas Limite / Fraude (security)
- Verificação de Saldo Conta do cliente (data)
- Ledger Débito na conta origem (data)
- Conector SPI Mensageria ISO 20022 (messaging)

### 🏛️ BACEN / SPI

- SPI (BACEN) Sistema de Pagamentos Instantâneos (external)
- Conta de Reservas Debita remetente / Credita destinatário (data)

### 🏦 Banco Destinatário

- Conector SPI Recebe confirmação (messaging)
- Ledger Crédito na conta destino (data)
- Notificação Push / SMS cliente destino (frontend)

### Fluxos

- app -> api_pix: 1. Instrução de pagamento (chave Pix, valor)
- api_pix -> politicas: 2. Verifica limite e risco de fraude
- api_pix -> saldo: 3. Verifica saldo disponível
- api_pix -> ledger_rem: 4. Débito na conta do cliente (reserva)
- ledger_rem -> conector_spi: 5. Envia mensagem ISO 20022 ao SPI
- conector_spi -> spi: 6. Ordem de pagamento
- spi -> reservas: 7. Debita reservas do banco remetente
- reservas -> spi: 8. Credita reservas do banco destinatário
- spi -> conector_dest: 9. Confirmação de liquidação
- conector_dest -> ledger_dest: 10. Crédito na conta do cliente destino
- ledger_dest -> notif: 11. Notifica cliente destino
- spi -> conector_spi: 12. Confirmação ao remetente (≤10s total)

## Por que o ledger é o coração — e por que mexer nele é cirurgia cardíaca

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.

## Por onde começar — checklist mental para o arquiteto que está chegando num banco

- ✅ Antes de qualquer reunião técnica, peça o mapa de capacidades de negócio do banco. Se não existir, desenhe um com base nesta aula e valide com o negócio.
- ✅ Identifique onde fica o ledger: qual sistema, qual tecnologia, qual equipe, quais os horários de fechamento e reconciliação.
- ✅ Aprenda a diferença entre saldo disponível, saldo contábil e limite. São três números diferentes e confundi-los gera bugs sérios.
- ✅ Mapeie os trilhos de pagamento que o banco usa (Pix, TED, boleto, cartão) e entenda qual infraestrutura do BACEN cada um usa. A Parte 2 desta série aprofunda isso.
- ✅ Use o Architecture Elevator: antes de propor uma solução técnica, suba ao andar de negócio e entenda qual capacidade você está servindo e qual regulação se aplica.
- ✅ Pergunte sobre o ciclo de liquidação de cada produto. Liquidação instantânea (Pix), D+0 (TED), D+1 (boleto), D+30 (cartão de crédito) — cada um tem implicações de design completamente diferentes.

> **Minha perspectiva — para quem está considerando essa transição:** Trabalhei mais de 16 anos em sistemas financeiros, incluindo plataformas de pagamento, crédito e dados de grau financeiro. A transição do mundo de software para o mercado financeiro é uma das mais ricas que um arquiteto pode fazer — e também uma das mais traiçoeiras se feita sem preparação.

O que mais vejo acontecer: o engenheiro chega com ótimas habilidades técnicas, propõe uma arquitetura elegante, e depois descobre que ela viola uma circular do BACEN que ninguém mencionou na reunião. Ou que o sistema de ledger que ele assumiu ser um microserviço moderno é na verdade um mainframe de 1987 que processa o fechamento às 23h e não pode ser tocado.

Meu conselho prático: **invista as primeiras semanas no andar de negócio, não no andar técnico**. Converse com o pessoal de compliance, de risco, de operações. Leia as circulares do BACEN relevantes para o produto que você vai construir. Entenda o ciclo de vida de uma transação do ponto de vista contábil antes de desenhar qualquer API.

O mercado financeiro paga bem e tem problemas técnicos genuinamente difíceis — escala, consistência, latência, segurança, auditabilidade. Mas esses problemas só fazem sentido quando você entende o negócio que os gera. Este guia é o ponto de partida. As Partes 2 e 3 vão descer mais fundo. Mas sem esta base, você vai construir soluções tecnicamente corretas para problemas que o negócio não tem.

## Conclusão da Parte 1 — o que você tem agora

Você saiu desta aula com o mapa mental de um banco: entende que o negócio central é intermediação financeira (captação + crédito = spread), que o BACEN é o árbitro regulatório que define as regras do jogo, que o ledger é o coração insubstituível do sistema, e que cada capacidade de negócio (conta, crédito, cartões, pagamentos, tesouraria, compliance, risco) tem um papel específico e consequências técnicas específicas.

Você também tem o framework do Architecture Elevator de Hohpe para navegar entre andares: regulatório → negócio → capacidades → técnico. Nunca pule andares.

O que vem a seguir: a **Parte 2** desta série mergulha nos trilhos de pagamento do Brasil — SPB, SPI (Pix), STR (TED/reservas), CIP (boletos), e como o BACEN opera essa infraestrutura. É onde a regulação se torna protocolo. A **Parte 3** desce ao andar técnico: arquitetura de sistemas de um banco moderno, padrões de ledger, event sourcing financeiro, e como montar uma plataforma bancária que escala sem quebrar.

Esta série não é sobre hype de fintech. É sobre entender um sistema complexo, regulado, e crítico o suficiente para que você possa contribuir com competência — e não apenas com código.

## Referências

- [Gregor Hohpe — The Software Architect Elevator (book)](https://architectelevator.com/book/)
- [Banco Central do Brasil — Portal oficial](https://www.bcb.gov.br/)
- [BACEN — Sistema de Pagamentos Brasileiro (SPB)](https://www.bcb.gov.br/estabilidadefinanceira/spb)
- [BACEN — Pix: regulamento e documentação técnica](https://www.bcb.gov.br/estabilidadefinanceira/pix)
- [BACEN — Sistema de Informações de Crédito (SCR)](https://www.bcb.gov.br/acessoinformacao/scr)
- [BACEN — Resolução CMN 4.557 (Gestão de Riscos)](https://www.bcb.gov.br/pre/normativos/busca/downloadNormativo.asp?arquivo=/Lists/Normativos/Attachments/50598/Res_4557_v1_O.pdf)
- [Gregor Hohpe — Architecture Elevator blog](https://architectelevator.com/)

## Fontes do caso

- [Gregor Hohpe — The Software Architect Elevator](https://architectelevator.com/book/)
- [Banco Central do Brasil](https://www.bcb.gov.br/)
- [BACEN — Sistema de Pagamentos Brasileiro (SPB)](https://www.bcb.gov.br/estabilidadefinanceira/spb)