# Inside a Bank (1/3): how a bank works — business view and the architecture elevator

First lesson in a three-part series for developers and architects moving into financial services. Covers what a bank is, why it exists, how money becomes product, and how the architect uses Gregor Hohpe's 'elevator' to move between the business floor and the technical floor. Brazil/BACEN focus.

- 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=en

- Type: Guide / 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

---

If you come from the software world and received an offer to work at a bank — or at a fintech that needs to behave like one — you probably felt that strange sensation: the vocabulary is different, meetings are full of acronyms nobody explains, and documentation assumes you already know what a 'ledger', a 'spread', or a 'treasury position' is. This guide exists to remove that barrier. I won't talk about systems yet. I'll start on the top floor — the business — and ride the elevator down to the technical ground floor with you, exactly as Gregor Hohpe describes in 'The Software Architect Elevator'. By the end of this first part, you'll understand what a bank does, why each area exists, and how money actually flows. Parts 2 and 3 of this series cover, respectively, payment rails and BACEN, and the systems architecture of a modern bank.

## What you will learn in this lesson

- What financial intermediation is and why a bank is not a 'money box'
- The concept of banking spread in engineering language (margin between cost and revenue)
- How to use Hohpe's Architecture Elevator to navigate between business and technology in a bank
- The complete business capability map of a bank: account, credit, cards, payments, treasury, FX, investments, compliance/AML, risk
- The 'conceptual engines': ledger, account, limit, settlement, boleto issuer, portfolio — what each one means
- How money enters and leaves a bank (deposit, Pix, TED, withdrawal, payment)

## Quick glossary — terms that appear in this lesson

- **Bank / Financial Institution:** A company authorized by BACEN to take deposits from the public and grant credit. Think of it as a regulated, trusted intermediary.
- **BACEN (Central Bank of Brazil):** Regulator and supervisor of the national financial system. Sets the rules of the game and operates the payments infrastructure (SPB).
- **Financial intermediation:** The bank takes money from those who have it (depositors) and lends it to those who need it (borrowers). This is the core business.
- **Banking spread:** The difference between the rate the bank charges on a loan and the rate it pays to the depositor. It is the gross margin of the main product.
- **Ledger (General Ledger):** Central accounting record where every money movement is recorded as a debit or credit on an account. It is the bank's 'real database'.
- **Settlement:** The moment when money actually changes hands between institutions. Before settlement, there is only a promise.
- **Boleto issuer:** System that generates boletos bancários — widely used billing documents in Brazil for payments.
- **Portfolio (credit):** The set of all active credit contracts of a bank. Think of it as an array of Loan objects with status, balance, and risk.
- **AML (Anti-Money Laundering):** Set of mandatory controls to detect and report suspicious operations to COAF (Brazil's financial intelligence unit).
- **SPB (Brazilian Payment System):** Infrastructure operated by BACEN that connects all financial institutions for payment settlement in Brazil.

## What is a bank — the engineer's analogy

Imagine you built a distributed cache system. You have nodes that temporarily store data for other nodes that need it. A bank works analogously, but with money and a time dimension: it stores money from those who have it (the **depositors**) and makes it available to those who need it now (the **borrowers**). This operation has a name: **financial intermediation**.

The critical difference for the engineer to understand is that the bank does not keep your money in a vault waiting for you to ask for it back. It lends it to someone else. When you deposit R$ 1,000, the bank records a **liability** to you (it owes you R$ 1,000 + interest) and simultaneously creates an **asset** by lending that money to a borrower at a higher rate. The difference between the rate it charges the borrower and the rate it pays you is the **banking spread** — the gross margin of the main product.

In engineering terms: the bank is a risk and time transformation system. It takes short-term resources (deposits you can withdraw tomorrow) and transforms them into long-term resources (36-month loans). This creates a structural risk called **maturity mismatch** — and managing this risk is one of the reasons BACEN requires minimum capital and compulsory reserves. Without regulation, this system collapses easily (as we saw in 2008 in the US).

The bank's product, therefore, is not money itself — money is the raw material. The product is **intermediated trust**: the certainty that you can deposit today and withdraw tomorrow, and that the borrower will receive the promised credit. All of a bank's technology architecture exists to sustain this trust at scale.

## The Architecture Elevator in a bank — why you need to go up before going down

Gregor Hohpe describes the modern software architect as someone who is not stuck on a single floor. They ride up to the **executive floor** (where strategy, regulation, and product live) and down to the **technical floor** (where code, infrastructure, and data live), translating the language of one to the other. In a bank, this ability is not optional — it is the number-one requirement.

Why? Because business decisions in a bank have immediate technical consequences and vice versa. Example: BACEN decides that Pix must settle in up to 10 seconds, 24 hours a day, 365 days a year. This is not a feature request — it is a regulatory constraint with a fine attached. The architect who understands only the technical floor will design an excellent asynchronous messaging system, but will miss the SLA. The architect who understands only the business will promise the SLA without knowing that the legacy ledger system has a maintenance window at 2 a.m.

Hohpe's elevator, applied to banks, has at least four floors:

1. **Regulatory floor** — BACEN, CMN, CVM, COAF. The non-negotiable rules.
2. **Business floor** — products, revenues, customers, credit risk, spread.
3. **Capabilities floor** — what the bank knows how to do: process payments, grant credit, issue cards.
4. **Technical floor** — systems, APIs, databases, queues, infrastructure.

This first lesson covers floors 1, 2, and 3. Part 2 deepens the regulatory floor with SPB rails. Part 3 descends to the technical floor with systems architecture. My advice for those transitioning: **do not jump to the technical floor before understanding the floors above**. You will build the right solution for the wrong problem.

## Diagram 1 — Bank context: actors and ecosystem

Who interacts with a bank and why. Read from outside in: external actors define the obligations; the bank orchestrates; BACEN arbitrates.

### 🏛️ 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)

### Flows

- pf -> conta: deposits / withdraws
- pf -> credito: requests credit
- pf -> pagamentos: sends Pix / pays boleto
- pj -> cartoes: accepts / issues card
- pagamentos -> spb: settles via SPB/SPI
- cartoes -> bandeiras: authorization / settlement
- tesouraria -> b3: buys/sells securities
- credito -> bureaus: queries score / SCR
- compliance -> coaf: reports suspicious ops
- bacen -> conta: regulation + compulsory reserve
- bacen -> spb: operates infrastructure

## Capability map — what a bank knows how to do

A **business capability map** is different from an org chart. It describes *what* the organization knows how to do, regardless of how it is internally structured. For an engineer, think of it as the public interfaces of a system — what it exposes, not how it is implemented.

A typical commercial bank in Brazil has the following business capabilities:

- **Checking and savings accounts**: opening, maintenance, balance, statement. This is the customer entry point. Without an account, there is no relationship.
- **Credit**: analysis, granting, management, and collection of loans, financing, and credit lines. This is where the bank generates most of its revenue (spread).
- **Cards**: issuance of debit and credit cards, transaction processing, billing, collection. Can be proprietary or via partnership with card networks (Visa, Mastercard).
- **Payments**: execution of Pix, TED, DOC, boletos, direct debit. This is the money movement engine.
- **Treasury**: management of the bank's own liquidity, buying and selling public and private securities, FX hedging. The bank also invests for itself.
- **Foreign exchange (FX)**: buying and selling foreign currency for customers and for the bank's own position.
- **Investments**: distribution of investment products (CDB, LCI, funds, equities) to customers.
- **Guarantees and sureties**: the bank guarantees third-party obligations (e.g., letter of credit for imports).
- **Recovery and collections**: management of non-performing credits, negotiation, sale of portfolios to recovery funds.
- **Compliance and AML**: monitoring of suspicious operations, KYC (know your customer), reporting to COAF.
- **Risk**: management of credit, market, liquidity, and operational risk. Regulatory obligation (Basel III).
- **Policies and limits**: definition and enforcement of operational limits (e.g., Pix limit per customer, credit limit).

Each of these capabilities will be implemented, at the technical floor (Part 3), by one or more systems. The classic mistake of the engineer arriving at a bank is trying to map systems before understanding capabilities.

## Diagram 2 — Bank business capability map

Capabilities grouped by domain. Each block is a 'business interface' — what the bank knows how to do, not how it does it. The architect uses this map to locate where a technical decision has impact.

### 💰 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)

### Flows

- cap_conta -> cap_ledger: every movement
- cap_credito -> cap_ledger: disbursement / installment
- cap_pix -> cap_liquidacao: SPI settlement
- cap_ted -> cap_liquidacao: STR settlement
- cap_cartao -> cap_liquidacao: network settlement
- cap_politicas -> cap_credito: credit limit
- cap_politicas -> cap_pix: Pix limit
- cap_pld -> cap_conta: monitors operations
- cap_risco -> cap_credito: score / provision

## Bank payment rails — what each one is for
| Criterion | Modality | Speed | Typical limit | Availability | Main use case |
| --- | --- | --- | --- | --- | --- |
| Pix | Instant (≤10s) | No defined limit (bank sets it) | 24/7/365 | P2P transfers, merchant payments, government | SPI (Instant Payment System) |
| TED | Same day (D+0) | No regulatory minimum limit | Business days, business hours | High-value transfers between banks | STR (Reserves Transfer System) |
| DOC | D+1 (next day) | Up to R$ 4,999.99 | Business days | Small-value transfers (legacy, being phased out) | SILOC / STR |
| Boleto Bancário | D+1 to D+2 (clearing) | Any value | Business days (payment accepted 24/7 on digital channels) | Customer billing, bill payment | CIP / ISPB |
| Direct Debit | D+0 (scheduled) | Defined by contract | Business days | Recurrence: subscriptions, utility bills | SITRAF / STR |
| Credit Card | Immediate authorization; D+30 settlement (bill) | Customer credit limit | 24/7 (authorization) | Installment purchases, e-commerce, travel | Card networks (Visa/MC) + CIP |

## The bank's conceptual engines — the vocabulary you will hear every day

Before seeing any system diagram, you need to internalize six concepts that appear in every technical conversation at a bank. These are the 'primitive types' of the financial domain.

**1. Ledger (General Ledger):** This is the central accounting record. Every money movement — deposit, withdrawal, payment, reversal — is recorded as a pair of entries: a **debit** (value leaving an account) and a **credit** (value entering another account). This is **double-entry bookkeeping**, invented in the 15th century. The ledger is the bank's 'real database'. If the ledger says you have R$ 1,000, you have R$ 1,000 — regardless of what any other system shows. In modern systems, the ledger is often a separate, immutable, append-only service.

**2. Account:** An account is an identifier that aggregates entries in the ledger. Do not confuse it with 'customer checking account' — that is just one type. There are customer accounts, revenue accounts, provision accounts, reserve accounts. Think of an account as a `Map<String, List<Entry>>` where the key is the account identifier.

**3. Limit:** A limit is a constraint on how much can be moved in an account or operation. Credit limit, daily Pix limit, withdrawal limit. It is a policy parameter, not a balance. Confusing limit with balance is a classic bug from someone coming from the e-commerce world.

**4. Settlement:** The moment when the financial obligation becomes final and irrevocable between institutions. Before settlement, a transaction is just an intention. After settlement, it is an accounting fact. In Pix, settlement happens in seconds via SPI. In credit cards, it can take days.

**5. Boleto issuer:** The system that generates and registers boletos bancários. A boleto has a barcode, a due date, a value, and is registered in a clearing house (CIP). When the payer pays, the clearing system notifies the beneficiary's bank to credit the account.

**6. Portfolio (credit):** The set of active credit contracts. Each contract has an outstanding balance, an interest rate, a term, and a status (current, overdue, in collection, written off). The 'health' of the portfolio is measured by **delinquency** (% of balance overdue) and **provision** (how much the bank has reserved to cover expected losses).

## Money flow — inflows and outflows of a bank

For an engineer, the bank can be modeled as a queue system with two types of events: **inflows** and **outflows**. Each event has an origin, destination, value, and needs to be settled and recorded in the ledger.

**Inflows (money arriving at the bank):**
- **Cash deposit**: customer goes to a branch or ATM, hands over banknotes. The teller records a credit on the customer's account and a debit on the cash account.
- **Received Pix**: another institution sends a message to the SPI (Instant Payment System). BACEN debits the sending bank's reserve account and credits the receiving bank's. The receiving bank then credits the customer's account.
- **Received TED**: similar to Pix, but via STR (Reserves Transfer System), during business hours.
- **Payroll credit (DOC/TED)**: a company sends a batch credit file to the bank, which distributes to employee accounts.
- **Boleto payment**: a customer from another bank pays a boleto issued by your bank. The clearing house (CIP) processes and notifies the bank to credit the beneficiary.

**Outflows (money leaving the bank):**
- **Withdrawal**: customer withdraws cash. Debit on customer account, credit on cash account (which is later replenished).
- **Sent Pix**: customer instructs the bank to send money. The bank checks balance and limit, sends a message to SPI, BACEN debits the bank's reserves and credits the recipient.
- **Bill payment (boleto/direct debit)**: debit on customer account, credit to the clearing house, which forwards to the beneficiary.
- **Debit card purchase**: immediate authorization, debit on customer account, credit on the bank's settlement account, which later forwards to the merchant via the card network.

The critical point: **every outflow needs available balance or approved limit**. And every movement — inflow or outflow — needs a corresponding entry in the ledger. Without this, the bank cannot close its balance sheet.

## Diagram 3 — End-to-end flow: an outgoing Pix

Follow the numbers: the customer instructs, the bank validates, SPI settles, the ledger records. Each arrow is an obligation that must be honored in ≤10 seconds.

### 👤 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)

### Flows

- app -> api_pix: 1. Payment instruction (Pix key, value)
- api_pix -> politicas: 2. Checks limit and fraud risk
- api_pix -> saldo: 3. Checks available balance
- api_pix -> ledger_rem: 4. Debit on customer account (reserve)
- ledger_rem -> conector_spi: 5. Sends ISO 20022 message to SPI
- conector_spi -> spi: 6. Payment order
- spi -> reservas: 7. Debits sending bank reserves
- reservas -> spi: 8. Credits receiving bank reserves
- spi -> conector_dest: 9. Settlement confirmation
- conector_dest -> ledger_dest: 10. Credit on destination customer account
- ledger_dest -> notif: 11. Notifies destination customer
- spi -> conector_spi: 12. Confirmation to sender (≤10s total)

## Why the ledger is the heart — and why touching it is open-heart surgery

If you look at Diagram 3 carefully, you will notice that the ledger appears in two places: at the sending bank (step 4) and at the receiving bank (step 10). This is not an accident — it is the fundamental architecture. **Every financial event with real consequences needs to be recorded in the ledger**. Without this record, the bank does not know how much it owes customers, how much customers owe it, and cannot close the accounting balance sheet required by BACEN.

The ledger is therefore the most critical system in a bank — more critical than the app, more critical than the website, more critical than the CRM. If the app goes down, the customer loses access. If the ledger corrupts an entry, the bank has a regulatory, legal, and trust problem all at once.

This explains some behaviors that seem strange to those coming from the startup world:

- **Maintenance windows**: legacy ledger systems (mainframe COBOL, for example) need windows to process daily closings. This is real and still happens in 2024 at many Brazilian banks.
- **Resistance to schema changes**: a new field in the ledger can break decades of regulatory reports. Every change is a risk operation.
- **Double validation and reconciliation**: banks have reconciliation processes that compare the internal ledger with BACEN statements. Any difference is an incident.

For the architect who is arriving: **understand the ledger before proposing any system change**. Know who operates it, what the technology is, what the closing times are, and what the reconciliation processes are. This is the map of the minefield.

## Where to start — mental checklist for the architect arriving at a bank

- ✅ Before any technical meeting, ask for the bank's business capability map. If it doesn't exist, draw one based on this lesson and validate with the business.
- ✅ Identify where the ledger is: which system, which technology, which team, what are the closing and reconciliation times.
- ✅ Learn the difference between available balance, accounting balance, and limit. These are three different numbers and confusing them causes serious bugs.
- ✅ Map the payment rails the bank uses (Pix, TED, boleto, card) and understand which BACEN infrastructure each one uses. Part 2 of this series goes deeper on this.
- ✅ Use the Architecture Elevator: before proposing a technical solution, go up to the business floor and understand which capability you are serving and which regulation applies.
- ✅ Ask about the settlement cycle of each product. Instant settlement (Pix), D+0 (TED), D+1 (boleto), D+30 (credit card) — each has completely different design implications.

> **My perspective — for those considering this transition:** I have worked for over 16 years in financial systems, including payment platforms, credit, and financial-grade data. The transition from the software world to financial services is one of the richest an architect can make — and also one of the most treacherous if done without preparation.

What I see happening most often: the engineer arrives with excellent technical skills, proposes an elegant architecture, and then discovers it violates a BACEN circular that nobody mentioned in the meeting. Or that the ledger system they assumed was a modern microservice is actually a 1987 mainframe that processes the closing at 11 p.m. and cannot be touched.

My practical advice: **invest the first weeks on the business floor, not the technical floor**. Talk to compliance, risk, and operations people. Read the BACEN circulars relevant to the product you will build. Understand the lifecycle of a transaction from an accounting perspective before designing any API.

The financial market pays well and has genuinely hard technical problems — scale, consistency, latency, security, auditability. But those problems only make sense when you understand the business that generates them. This guide is the starting point. Parts 2 and 3 will go deeper. But without this foundation, you will build technically correct solutions for problems the business does not have.

## Part 1 conclusion — what you have now

You finished this lesson with the mental map of a bank: you understand that the core business is financial intermediation (funding + credit = spread), that BACEN is the regulatory arbiter that sets the rules of the game, that the ledger is the irreplaceable heart of the system, and that each business capability (account, credit, cards, payments, treasury, compliance, risk) has a specific role and specific technical consequences.

You also have Hohpe's Architecture Elevator framework to navigate between floors: regulatory → business → capabilities → technical. Never skip floors.

What comes next: **Part 2** of this series dives into Brazil's payment rails — SPB, SPI (Pix), STR (TED/reserves), CIP (boletos), and how BACEN operates this infrastructure. This is where regulation becomes protocol. **Part 3** descends to the technical floor: systems architecture of a modern bank, ledger patterns, financial event sourcing, and how to build a banking platform that scales without breaking.

This series is not about fintech hype. It is about understanding a complex, regulated, and critical enough system so that you can contribute with competence — not just with code.

## References

- [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/)

## Case sources

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