# Inside a Bank (2/3): the rails and the rules — payments, BACEN and bank × fintech

Lesson 2 of 3 in the 'Inside a Bank' series: explains how money moves between institutions in Brazil (SPB, Pix, TED, card, boleto, FX, investments), what the Central Bank requires to operate, and what changes when you are a fintech rather than a fully licensed bank. Maximum didactics for engineers and architects coming from tech.

- URL: https://fernando.moretes.com/studies/banco-por-dentro-2-trilhos-e-regulacao

- Markdown: https://fernando.moretes.com/studies/banco-por-dentro-2-trilhos-e-regulacao/study.md?lang=en

- Type: Guide / Deep Dive

- Domain: Mercado Financeiro

- Date: 2026-06-21

- Tags: payments, SPB, Pix, BACEN, fintech, banking, Brazil, financial-architecture

- Reading time: 10 min

---

If you come from tech and have joined (or want to join) the financial market, Part 1 of this series showed you what a bank *does* — its business capabilities. Now we ride the Architecture Elevator one floor down and look at the *rails*: the infrastructures that move money between institutions, the rules the Central Bank imposes, and what actually separates a bank from a fintech. Understanding this is a prerequisite for any serious technical conversation about financial systems in Brazil — from designing a payments microservice to evaluating whether your company needs a licence or can operate on top of a partner.

## What you will learn in this lesson

- What the SPB (Brazilian Payment System) is and why it exists
- Each payment rail: Pix, TED, DOC, boleto, card (4-party model), FX and investments — explained from scratch
- How Pix works technically: DICT, SPI and real-time settlement
- The 4-party card model: cardholder, issuer, acquirer and scheme
- What BACEN requires: licence types, minimum capital, AML/CFT, SCR and reserve requirements
- Bank × fintech: what changes in practice — BaaS, SCD, IP and full bank

## Quick glossary — terms that appear in this lesson

- **SPB:** Brazilian Payment System — the set of rules, clearing houses and systems that move money between institutions in Brazil. Think of it as the 'operating system' of money.
- **BACEN / BCB:** Central Bank of Brazil — the regulator and operator of part of the financial infrastructure. It is simultaneously referee, supervisor and owner of some rails.
- **Settlement:** The moment money *actually* changes hands between institutions. Authorising a payment ≠ settling. Think of authorisation as a 'commit' and settlement as the 'flush to disk'.
- **SPI:** Instant Payment System — the Pix rail, operated by BACEN. Settles in up to 10 seconds, 24/7/365.
- **DICT:** Directory of Transactional Account Identifiers — the 'DNS of Pix'. Resolves a key (CPF, e-mail, phone, random key) to the destination bank account.
- **STR:** Reserves Transfer System — the TED rail, operated by BACEN. Settles in real time but only during business hours.
- **PSP:** Payment Service Provider — any institution that connects users to the SPB (banks, fintechs, IPs).
- **IP (Payment Institution):** Lighter regulatory licence than a bank. Can issue prepaid cards, maintain payment accounts, but CANNOT lend money using client funds.
- **SCD:** Direct Credit Company — licence that allows lending own money (without taking public deposits). Typical credit fintech.
- **BaaS:** Banking as a Service — model where a fintech uses a partner bank's licence and infrastructure via API, instead of obtaining its own licence.

## The Architecture Elevator: from the business floor to the rails floor

Gregor Hohpe describes the architect as someone who can move between the executive floor — where the talk is of strategy, regulation and risk — and the technical floor — where the talk is of protocols, latency and eventual consistency. In financial services, this skill is especially critical because the two floors are inseparable: a BACEN regulatory decision (top floor) can require an architecture change in 90 days (bottom floor).

In Part 1 of this series, we stayed on the business floor: what a bank *does* — funding, credit, payments, FX, custody. Now we descend to the **rails** floor: the concrete infrastructure that executes those capabilities. A 'payment rail' is, for an engineer, analogous to a *transport layer*: it is the standardised channel through which debit/credit messages flow between institutions, with rules about hours, settlement, message format and error responsibility.

Brazil has one of the most sophisticated payment systems in the world — not by accident, but because BACEN spent decades building public infrastructure and regulating participant entry. The SPB (Brazilian Payment System) is the name for the whole set: it includes clearing houses, settlement systems and the rails themselves. Understanding the SPB means understanding the design constraints of any Brazilian financial system.

## Diagram 1 — SPB Map: rails, clearing houses and participants

Overview of the Brazilian Payment System. Each rail has its own settlement system and participant set. BACEN operates the SPI (Pix) and STR (TED/reserves). B3 operates the clearing house for securities and equities.

### 🏛️ BACEN — Infraestrutura Pública / Public Infrastructure

- SPI (Pix — tempo real / real-time) (messaging)
- DICT (Diretório de chaves Pix / Pix key directory) (data)
- STR (TED — reservas bancárias / bank reserves) (messaging)
- SCR (Cadastro de crédito / Credit registry) (data)

### 🏦 Participantes Diretos / Direct Participants

- Banco A (banco múltiplo / full bank) (compute)
- Banco B (banco múltiplo / full bank) (compute)
- Fintech IP (Instituição de Pagamento) (compute)
- Fintech SCD (Sociedade de Crédito Direto) (compute)

### 🏗️ Câmaras Privadas / Private Clearing Houses

- B3 (ações, títulos / equities, bonds) (external)
- Adquirentes (cartão / card: Cielo, Rede, Stone…) (external)
- CIP / Nuclea (boleto, DOC, TED privado) (external)

### 👤 Usuários Finais / End Users

- Pagador (pessoa física/jurídica) (user)
- Recebedor (pessoa física/jurídica) (user)

### Flows

- pagador -> banco_a: initiates payment
- banco_a -> spi: Pix (ISO 20022)
- banco_a -> dict: resolves key
- spi -> banco_b: account credit
- banco_b -> recebedor: notifies recipient
- banco_a -> str: TED (business hours)
- str -> banco_b: bank reserves
- banco_a -> cip: boleto / DOC
- ip_fintech -> spi: SPI direct participant
- scd_fintech -> banco_a: BaaS / settlement partner
- banco_a -> scr: reports credit (monthly)
- banco_a -> b3: custody / D+2 settlement

## The rails one by one: from Pix to FX

**Pix** is the newest rail and the most important to understand first. Launched in November 2020, it operates 24/7/365 and settles in up to 10 seconds. Technically, it uses the ISO 20022 protocol (structured XML messages — think 'JSON with mandatory schema validated by the regulator'). There are two central components: the **SPI** (the rail itself, which moves reserves between PSP accounts at BACEN) and the **DICT** (the directory that resolves keys — works exactly like DNS: you give a human-readable name, you get an account address back). When you pay with Pix, your app queries DICT to find which bank holds the recipient's account, then sends the payment order via SPI. BACEN debits your PSP's reserve account and credits the recipient PSP's reserve account — all in seconds.

**TED** (Electronic Available Transfer) is the rail that preceded Pix. It uses the STR, also operated by BACEN, but only works during business hours (roughly 6:30–17:30 on business days). Settles in real time within that window. Still relevant for high-value inter-company transfers.

**DOC** (Credit Order Document) is pure legacy: next-day settlement (D+1), cap of BRL 4,999.99, batch-processed. Being phased out — Pix made it irrelevant.

**Boleto** is a billing instrument (not a transfer): the payer can pay at any bank, lottery outlet or app. Clearing is done by CIP/Nuclea. Settlement D+1 or D+2. Still widely used for B2B and e-commerce.

**FX** (international transfer) involves the SWIFT network for messaging between correspondent banks and a mandatory **câmbio contract** in Brazil — every currency conversion must be registered with BACEN. Typical latency: 1–3 business days. High cost. Brazilian FX regulation is among the most complex in the world.

**Investments**: equities and private bonds settle at B3 in D+2 (two business days after trading). Government bonds (Tesouro Direto) settle via Selic/BACEN. CDBs are book-entry — they exist as accounting records at the issuing bank, with no clearing house settlement.

## Diagram 2 — Full Pix flow (payer → PSP → SPI/DICT → PSP → recipient)

Technical flow of a Pix transaction. Numbers on edges indicate sequence. DICT is queried before SPI. Settlement (reserve debit/credit) happens in SPI in milliseconds. Notification to the recipient is asynchronous.

### 👤 Lado do Pagador / Payer Side

- App do Pagador (mobile/web) (frontend)
- PSP Pagador (banco ou IP) (compute)
- Core Bancário Pagador (débito na conta) (data)

### 🏛️ BACEN — Infraestrutura Central / Central Infrastructure

- DICT (resolve chave → ISPB + conta) (data)
- SPI (liquida reservas em <10s) (messaging)
- Conta Reservas PSP Pagador (data)
- Conta Reservas PSP Recebedor (data)

### 👤 Lado do Recebedor / Recipient Side

- PSP Recebedor (banco ou IP) (compute)
- Core Bancário Recebedor (crédito na conta) (data)
- App do Recebedor (notificação push) (frontend)

### Flows

- payer_app -> psp_payer: 1. initiates Pix (destination key)
- psp_payer -> dict_node: 2. GET /dict/key → ISPB+account
- dict_node -> psp_payer: 3. returns recipient data
- psp_payer -> psp_payer_core: 4. debits payer account
- psp_payer -> spi_node: 5. sends ISO 20022 msg (pain.001)
- spi_node -> reservas_payer: 6. debits payer PSP reserves
- spi_node -> reservas_recv: 7. credits recipient PSP reserves
- spi_node -> psp_recv: 8. notifies recipient PSP (pain.002)
- psp_recv -> psp_recv_core: 9. credits recipient account
- psp_recv -> recv_app: 10. push notification (async)

## The 4-party card model: the topology every payments engineer needs to know

The credit/debit card seems simple to the user — you tap the card, the payment happens. Underneath, there are four distinct actors with separate contracts and money flows. Understanding this model is mandatory for any work in payments.

**Cardholder**: you, the card owner. Has a contract with the issuer.

**Issuer**: the bank or fintech that issued the card. Approves or declines the transaction based on the cardholder's balance/limit. Receives the largest share of interchange.

**Acquirer**: the company that connects the merchant to the card system (Cielo, Rede, Stone, PagSeguro…). Processes the POS terminal or online checkout. Pays the merchant (minus fees) and collects from the issuer.

**Scheme**: Visa, Mastercard, Elo, Amex. Sets the rules of the game — which messages, which timelines, which interchange fees. Does not touch the money directly; it is the referee and protocol owner.

The flow has two distinct phases: **authorisation** (milliseconds — the issuer approves or declines in real time) and **settlement** (D+1 or D+2 — money actually moves between acquirer and issuer via the scheme's clearing house). This creates intraday credit risk: the merchant receives the payment promise at authorisation, but the money only arrives days later. That is why acquirers have credit limits with issuers.

**MDR** (Merchant Discount Rate): the merchant does not receive 100% of the sale value. It pays a fee (typically 1–3%) split between acquirer, scheme and issuer (interchange). For the engineer: this means the value that appears at authorisation ≠ the value the merchant receives at settlement.

## Diagram 3 — 4-party card model: authorisation and settlement

Solid arrows show the authorisation flow (real time). Dashed arrows show the settlement flow (D+1/D+2). Money and messages travel different paths.

### 👤 Portador / Cardholder

- Portador (você / you) (user)

### 🏪 Lado do Lojista / Merchant Side

- Lojista (merchant) (user)
- Terminal POS / Checkout (frontend)
- Adquirente (Cielo, Stone, Rede…) (compute)

### 🏷️ Bandeira / Scheme

- Bandeira (Visa / MC / Elo) árbitro do protocolo (external)

### 🏦 Lado do Emissor / Issuer Side

- Emissor (banco / fintech) (compute)
- Core Bancário (limite / saldo) (data)

### 🏛️ Liquidação / Settlement

- Câmara da Bandeira (clearing D+1/D+2) (messaging)

### Flows

- cardholder -> pos: 1. presents card
- pos -> acquirer: 2. auth request (ISO 8583)
- acquirer -> scheme: 3. routes to scheme
- scheme -> issuer: 4. forwards to issuer
- issuer -> issuer_core: 5. checks limit/balance
- issuer -> scheme: 6. approves/declines (ms)
- scheme -> acquirer: 7. returns authorisation
- acquirer -> pos: 8. approved → sale OK
- acquirer -> clearing: 9. settlement batch D+1/D+2
- clearing -> issuer: 10. issuer debit
- clearing -> acquirer: 11. acquirer credit
- acquirer -> merchant: 12. merchant payout (minus MDR)

## BACEN as regulator: what it requires for you to operate

For an engineer coming from tech, financial regulation looks like bureaucracy. In practice, it defines the *design constraints* of the system — and ignoring it is the most expensive mistake a fintech can make.

**Licensing**: you cannot simply 'open bank accounts for third parties' or 'lend money' without BACEN authorisation. The main licence types are: (a) **Full Bank (Banco Múltiplo/Comercial)** — can do everything: take deposits, lend, issue cards, FX. Minimum capital around BRL 17–21 million (varies by portfolio). (b) **Payment Institution (IP)** — can maintain payment accounts and issue instruments (prepaid, postpaid card). Cannot lend with client money. Lower minimum capital. (c) **SCD (Direct Credit Company)** — can lend own money or funds raised via CRI/CRA/debentures. Cannot take public deposits. Minimum capital BRL 1 million. (d) **SEP (Peer-to-Peer Lending Company)** — credit marketplace.

**Minimum capital and Basel**: banks must maintain a capital ratio (Reference Equity / Risk-Weighted Assets) above a BACEN-defined minimum (currently ~10.5% + buffers). Simply: if you lend BRL 100 of high risk, you need ~BRL 10.5 of own capital as a buffer. This limits credit portfolio growth.

**AML/CFT**: every FI must have a compliance programme with KYC (Know Your Customer), transaction monitoring, suspicious activity reporting to COAF and staff training. For the engineer: this becomes a system requirement — you need anomaly detection pipelines, immutable logs and reporting APIs.

**SCR**: every FI that grants credit reports monthly to BACEN the credit operations of each client (CPF/CNPJ). BACEN aggregates and makes this history available for FI queries. It is the 'national credit database' — more complete than Serasa or SPC because it is mandatory.

**Reserve requirement (Compulsório)**: banks that take deposits must deposit a percentage at BACEN (currently ~20% of demand deposits). This reduces money available for lending and is a monetary policy tool. IP fintechs do not take deposits, so have no reserve requirement — but also cannot use client money to lend.

**Regulatory reporting**: beyond SCR, there are dozens of other periodic reports — DLO, COSIF (standard chart of accounts), CADOC, among others. A bank spends more time and money on compliance than most fintechs imagine.

## Bank × Fintech: what changes in practice (comparison table)
| Criterion | Dimension | Full Bank (Banco Múltiplo) | Fintech IP (Payment Institution) | Fintech SCD (Direct Credit) | Fintech without licence (BaaS) |
| --- | --- | --- | --- | --- | --- |
| BACEN licence | Full Bank / Commercial | Payment Institution | Direct Credit Company | None (uses partner's licence) | — |
| Can take deposits? | ✅ Yes (current account, CDB, savings) | ❌ No (payment account ≠ deposit) | ❌ No | ❌ No (depends on partner) | — |
| Can lend? | ✅ Yes (with deposited funds) | ❌ No (with client money) | ✅ Yes (own capital / issuance) | ⚠️ Only if partner is SCD/bank | — |
| Minimum capital (estimate) | BRL 17–21 million+ | BRL 2–7 million (by modality) | BRL 1 million | Zero (cost is the BaaS fee) | — |
| Direct SPI (Pix) access? | ✅ Direct participant | ✅ Direct participant (if enabled) | ⚠️ Via settlement bank | ❌ Via partner | — |
| AML/CFT obligations | ✅ Full (COAF, SCR, KYC…) | ✅ Full | ✅ Full | ⚠️ Shared with partner (contract) | — |
| Reserve requirement | ✅ Yes (~20% demand deposits) | ❌ No (no deposits) | ❌ No | ❌ No | — |
| Time to operate (estimate) | 12–36 months (BACEN process) | 6–18 months | 6–12 months | Weeks (depends on BaaS partner) | — |
| Typical business model | Credit spread + fees + float | MDR, account fees, interchange | Credit spread (own capital) | Digital product on third-party infrastructure | — |

## Bank × fintech: where BaaS solves and where it constrains

The table above shows the trade-offs, but it is worth deepening the architectural logic. A fintech operating on BaaS (Banking as a Service) is analogous to a SaaS application running on a cloud provider: you gain go-to-market speed and do not need to build the base infrastructure, but you pay a per-transaction fee, have customisation limits and are subject to the partner's policies.

BaaS in Brazil works like this: the partner bank (which holds a full licence) exposes APIs so the fintech can offer financial products to its clients. The fintech handles UX, onboarding, product — the bank handles settlement, reserve requirements, SCR and regulatory compliance. Common examples: white-label credit card, payment account, payroll-deductible credit via API.

The problem appears when the fintech wants to grow beyond what the partner allows or when it wants better margins. At that point, the decision to obtain a licence enters the picture. An IP gives independence in payments but not in credit. An SCD gives independence in credit but requires own capital and does not allow deposit-taking. A full bank gives everything — but the licensing process is long, expensive and the ongoing regulatory cost is high.

For the systems architect, the practical consequence is: the licence model defines which APIs you can expose, which data you must report, which systems you need to build internally (compliance engine, SCR feeder, COSIF accounting) and which you can outsource. Part 3 of this series will detail exactly those internal systems.

## Where to start: mental checklist for the architect entering financial services

- ✅ First, understand WHICH payment rail the system uses: Pix (SPI), TED (STR), card (scheme + acquirer), boleto (CIP) or FX (SWIFT). Each has different latency, cost and settlement rules.
- ✅ Separate authorisation from settlement in your mind — and in your data model. They are distinct events, at distinct times, with distinct consequences for consistency.
- ✅ Always ask: 'what is the company's licence?' This defines what the system CAN legally do and which reporting obligations exist.
- ✅ AML/CFT is not optional and is not just a form — it is a system requirement. You will need monitoring pipelines, immutable logs and COAF integration.
- ✅ SCR is bidirectional: the company reports credit to BACEN AND queries clients' credit history. Design both flows from the start.
- ✅ In the 4-party card model, always know who is the issuer and who is the acquirer in your context — the contracts, fees and responsibilities are completely different.

> **My take for someone making this career transition:** After 16 years working in financial systems — including banking-grade payment infrastructure —, the thing I most often see engineers and architects get wrong when entering financial services is treating regulation as the legal team's problem. It is not. Regulation is a system requirement. BACEN will not call you to ask you to fix the code — it will fine the company, suspend the licence or, in the limit, intervene. This changes the risk appetite of the entire organisation and, therefore, architecture decisions.

The second mistake is underestimating the complexity of the rails. Pix looks simple on the surface — and the UX genuinely is. But underneath there is ISO 20022, DICT with regulatory availability SLAs, reversal rules, real-time fraud and the need to settle reserves at BACEN. When you design a payments system, you are designing against those constraints, not against some arbitrary database.

My concrete recommendation: before writing a line of code on a financial project, read the regulation for the product you are going to build. Not all of it — read the specific BACEN normative for that rail or licence. It is dense, but it is the real specification of the system. Everything you build is an implementation of that specification.

## Conclusion: the rails define the constraints, the licence defines the perimeter

The Brazilian Payment System is a sophisticated public infrastructure — Pix is genuinely one of the best instant payment systems in the world, and BACEN deserves credit for that. For an architect coming from tech, the central message of this lesson is: each rail has its own rules of latency, settlement and compliance; each licence defines what you can and cannot do; and regulation is not bureaucracy — it is the system specification.

The bank × fintech × BaaS decision is not technological — it is strategic and regulatory. Technology executes strategy within regulatory constraints. The sooner the architect understands this, the better the design decisions will be.

In Part 3 of this series, we go one more floor down in the Elevator: we will look at the internal systems that execute all of this — core banking, ledger, credit engine, compliance engine and the event-driven architecture that connects everything.

## References

- [BACEN — Pix: visão geral e normativos](https://www.bcb.gov.br/estabilidadefinanceira/pix)
- [BACEN — Sistema de Pagamentos Brasileiro (SPB)](https://www.bcb.gov.br/estabilidadefinanceira/spb)
- [BACEN — SCR: Sistema de Informações de Crédito](https://www.bcb.gov.br/estabilidadefinanceira/scr)
- [Banco Central do Brasil — Portal principal](https://www.bcb.gov.br/)
- [Gregor Hohpe — The Software Architect Elevator (book)](https://architectelevator.com/)
- [BACEN — Resolução BCB nº 1 (Pix): regulamento do arranjo](https://www.bcb.gov.br/pre/normativos/busca/downloadNormativo.asp?arquivo=/Lists/Normativos/Attachments/51028/Res_BCB_0001_v6_P.pdf)
- [BACEN — Tipos de instituições autorizadas a funcionar](https://www.bcb.gov.br/estabilidadefinanceira/tiposinstituicoes)
- [BACEN — Índice de Basileia e capital mínimo](https://www.bcb.gov.br/estabilidadefinanceira/basileia)

## Case sources

- [BACEN — Pix](https://www.bcb.gov.br/estabilidadefinanceira/pix)
- [BACEN — Sistema de Pagamentos Brasileiro](https://www.bcb.gov.br/estabilidadefinanceira/spb)
- [BACEN — SCR (Sistema de Informações de Crédito)](https://www.bcb.gov.br/estabilidadefinanceira/scr)
- [Banco Central do Brasil](https://www.bcb.gov.br/)