# Banco por Dentro (2/3): os trilhos e as regras — pagamentos, BACEN e banco × fintech

Aula 2 de 3 da série 'Banco por Dentro': explica como o dinheiro se move entre instituições no Brasil (SPB, Pix, TED, cartão, boleto, câmbio, investimentos), o que o Banco Central exige para operar e o que muda quando você é uma fintech em vez de um banco com licença completa. Didática máxima para engenheiros e arquitetos vindos de 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=pt

- Type: Guia / Deep Dive

- Domain: Mercado Financeiro

- Date: 2026-06-21

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

- Reading time: 10 min

---

Se você vem de tech e entrou (ou quer entrar) no mercado financeiro, a Parte 1 desta série mostrou o que um banco *faz* — suas capacidades de negócio. Agora vamos descer um andar no Elevador da Arquitetura e olhar para os *trilhos*: as infraestruturas que movem dinheiro entre instituições, as regras que o Banco Central impõe e o que separa um banco de uma fintech na prática. Entender isso é pré-requisito para qualquer conversa técnica séria sobre sistemas financeiros no Brasil — desde desenhar um microsserviço de pagamentos até avaliar se sua empresa precisa de uma licença ou pode operar sobre um parceiro.

## O que você vai aprender nesta aula

- O que é o SPB (Sistema de Pagamentos Brasileiro) e por que ele existe
- Cada trilho de pagamento: Pix, TED, DOC, boleto, cartão (modelo de 4 partes), câmbio e investimentos — explicados do zero
- Como o Pix funciona tecnicamente: DICT, SPI e liquidação em tempo real
- O modelo de 4 partes do cartão: portador, emissor, adquirente e bandeira
- O que o BACEN exige: tipos de licença, capital mínimo, PLD/FT, SCR e compulsório
- Banco × fintech: o que muda na prática — BaaS, SCD, IP e banco múltiplo

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

- **SPB:** Sistema de Pagamentos Brasileiro — o conjunto de regras, câmaras e sistemas que movem dinheiro entre instituições no Brasil. Pense nele como o 'sistema operacional' do dinheiro.
- **BACEN / BCB:** Banco Central do Brasil — o regulador e operador de parte da infraestrutura financeira. É ao mesmo tempo árbitro, fiscal e dono de alguns trilhos.
- **Liquidação:** O momento em que o dinheiro *de fato* muda de mãos entre instituições. Autorizar um pagamento ≠ liquidar. Pense em autorização como um 'commit' e liquidação como o 'flush para disco'.
- **SPI:** Sistema de Pagamentos Instantâneos — o trilho do Pix, operado pelo BACEN. Liquida em até 10 segundos, 24/7/365.
- **DICT:** Diretório de Identificadores de Contas Transacionais — o 'DNS do Pix'. Resolve uma chave (CPF, e-mail, celular, chave aleatória) para a conta bancária de destino.
- **STR:** Sistema de Transferência de Reservas — o trilho da TED, operado pelo BACEN. Liquida em tempo real mas só em horário comercial.
- **PSP:** Provedor de Serviços de Pagamento — qualquer instituição que conecta usuários ao SPB (bancos, fintechs, IPs).
- **IP (Instituição de Pagamento):** Licença regulatória mais leve que banco. Pode emitir cartão pré-pago, manter conta de pagamento, mas NÃO pode emprestar dinheiro com recursos dos clientes.
- **SCD:** Sociedade de Crédito Direto — licença que permite emprestar dinheiro próprio (sem captar depósitos do público). Fintech de crédito típica.
- **BaaS:** Banking as a Service — modelo em que uma fintech usa a licença e infraestrutura de um banco parceiro via API, em vez de obter licença própria.

## O Elevador da Arquitetura: do andar do negócio ao andar dos trilhos

Gregor Hohpe descreve o arquiteto como alguém que consegue se mover entre o andar executivo — onde se fala em estratégia, regulação e risco — e o andar técnico — onde se fala em protocolos, latência e consistência eventual. No mercado financeiro, essa habilidade é especialmente crítica porque os dois andares são inseparáveis: uma decisão regulatória do BACEN (andar de cima) pode exigir uma mudança de arquitetura em 90 dias (andar de baixo).

Na Parte 1 desta série, ficamos no andar do negócio: o que um banco *faz* — captação, crédito, pagamentos, câmbio, custódia. Agora descemos para o andar dos **trilhos**: a infraestrutura concreta que executa essas capacidades. Um 'trilho de pagamento' é, para um engenheiro, análogo a um *transport layer*: é o canal padronizado pelo qual mensagens de débito/crédito trafegam entre instituições, com regras de horário, liquidação, formato de mensagem e responsabilidade por erros.

O Brasil tem um dos sistemas de pagamentos mais sofisticados do mundo — não por acidente, mas porque o BACEN investiu décadas construindo infraestrutura pública e regulando a entrada de participantes. O SPB (Sistema de Pagamentos Brasileiro) é o nome do conjunto: inclui câmaras de compensação, sistemas de liquidação e os próprios trilhos. Entender o SPB é entender as restrições de design de qualquer sistema financeiro brasileiro.

## Diagrama 1 — Mapa do SPB: trilhos, câmaras e participantes

Visão geral do Sistema de Pagamentos Brasileiro. Cada trilho tem seu próprio sistema de liquidação e conjunto de participantes. O BACEN opera o SPI (Pix) e o STR (TED/reservas). A B3 opera a câmara de compensação de títulos e ações.

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

### Fluxos

- pagador -> banco_a: inicia pagamento
- banco_a -> spi: Pix (ISO 20022)
- banco_a -> dict: resolve chave
- spi -> banco_b: crédito em conta
- banco_b -> recebedor: notifica recebedor
- banco_a -> str: TED (horário comercial)
- str -> banco_b: reservas bancárias
- banco_a -> cip: boleto / DOC
- ip_fintech -> spi: participante direto SPI
- scd_fintech -> banco_a: BaaS / parceiro liquidante
- banco_a -> scr: reporta crédito (mensal)
- banco_a -> b3: custódia / liquidação D+2

## Os trilhos um a um: do Pix ao câmbio

**Pix** é o trilho mais novo e o mais importante para entender primeiro. Lançado em novembro de 2020, opera 24/7/365 e liquida em até 10 segundos. Tecnicamente, usa o protocolo ISO 20022 (mensagens XML estruturadas — pense em 'JSON com schema obrigatório e validado por regulador'). Há dois componentes centrais: o **SPI** (o trilho em si, que move as reservas entre contas dos PSPs no BACEN) e o **DICT** (o diretório que resolve chaves — funciona exatamente como DNS: você dá um nome legível, recebe um endereço de conta). Quando você paga com Pix, seu app consulta o DICT para descobrir em qual banco está a conta do recebedor, depois envia a ordem de pagamento via SPI. O BACEN debita a conta de reservas do seu PSP e credita a conta de reservas do PSP do recebedor — tudo em segundos.

**TED** (Transferência Eletrônica Disponível) é o trilho anterior ao Pix. Usa o STR, também operado pelo BACEN, mas só funciona em horário comercial (aproximadamente 6h30–17h30 em dias úteis). Liquida em tempo real dentro desse janela. Ainda relevante para transferências de alto valor entre empresas.

**DOC** (Documento de Ordem de Crédito) é legado puro: liquidação no dia seguinte (D+1), limite de R$ 4.999,99, processado em lote. Está em processo de descontinuação — o Pix o tornou irrelevante.

**Boleto** é um instrumento de cobrança (não de transferência): o pagador pode pagar em qualquer banco, lotérica ou app. A compensação é feita pela CIP/Nuclea. Liquidação em D+1 ou D+2. Ainda amplamente usado para B2B e e-commerce.

**Câmbio** (transferência internacional) envolve o sistema SWIFT para mensageria entre bancos correspondentes e um **contrato de câmbio** obrigatório no Brasil — toda conversão de moeda precisa ser registrada no BACEN. Latência típica: 1–3 dias úteis. Custo alto. A regulação cambial brasileira é uma das mais complexas do mundo.

**Investimentos**: ações e títulos privados liquidam na B3 em D+2 (dois dias úteis após a negociação). Títulos públicos (Tesouro Direto) liquidam via Selic/BACEN. CDBs são escriturais — existem como registros contábeis no banco emissor, sem liquidação em câmara.

## Diagrama 2 — Fluxo completo do Pix (pagador → PSP → SPI/DICT → PSP → recebedor)

Fluxo técnico de uma transação Pix. Números nas arestas indicam a sequência. O DICT é consultado antes do SPI. A liquidação (débito/crédito de reservas) acontece no SPI em milissegundos. A notificação ao recebedor é assíncrona.

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

### Fluxos

- payer_app -> psp_payer: 1. inicia Pix (chave destino)
- psp_payer -> dict_node: 2. GET /dict/key → ISPB+conta
- dict_node -> psp_payer: 3. retorna dados do recebedor
- psp_payer -> psp_payer_core: 4. debita conta do pagador
- psp_payer -> spi_node: 5. envia msg ISO 20022 (pain.001)
- spi_node -> reservas_payer: 6. debita reservas PSP pagador
- spi_node -> reservas_recv: 7. credita reservas PSP recebedor
- spi_node -> psp_recv: 8. notifica PSP recebedor (pain.002)
- psp_recv -> psp_recv_core: 9. credita conta do recebedor
- psp_recv -> recv_app: 10. push notification (assíncrono)

## O modelo de 4 partes do cartão: a topologia que todo engenheiro de pagamentos precisa conhecer

O cartão de crédito/débito parece simples para o usuário — você passa o cartão, o pagamento acontece. Por baixo, há quatro atores distintos com contratos e fluxos de dinheiro separados. Entender esse modelo é obrigatório para qualquer trabalho em pagamentos.

**Portador** (cardholder): você, o dono do cartão. Tem contrato com o emissor.

**Emissor** (issuer): o banco ou fintech que emitiu o cartão. Aprova ou recusa a transação com base no saldo/limite do portador. Recebe a maior parte do interchange.

**Adquirente** (acquirer): a empresa que conecta o lojista ao sistema de cartões (Cielo, Rede, Stone, PagSeguro…). Processa o terminal POS ou o checkout online. Paga ao lojista (menos as taxas) e cobra do emissor.

**Bandeira** (scheme): Visa, Mastercard, Elo, Amex. Define as regras do jogo — quais mensagens, quais prazos, quais taxas de interchange. Não toca no dinheiro diretamente; é o árbitro e dono do protocolo.

O fluxo tem duas fases distintas: **autorização** (milissegundos — o emissor aprova ou recusa em tempo real) e **liquidação** (D+1 ou D+2 — o dinheiro de fato se move entre adquirente e emissor via câmara da bandeira). Isso cria um risco de crédito intradía: o lojista recebe a promessa de pagamento na autorização, mas o dinheiro só chega dias depois. É por isso que adquirentes têm limites de crédito com emissores.

**Taxa MDR** (Merchant Discount Rate): o lojista não recebe 100% do valor da venda. Paga uma taxa (tipicamente 1–3%) que é dividida entre adquirente, bandeira e emissor (interchange). Para o engenheiro: isso significa que o valor que aparece na autorização ≠ o valor que o lojista recebe na liquidação.

## Diagrama 3 — Modelo de 4 partes do cartão: autorização e liquidação

As setas sólidas mostram o fluxo de autorização (tempo real). As setas tracejadas mostram o fluxo de liquidação (D+1/D+2). O dinheiro e as mensagens percorrem caminhos diferentes.

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

### Fluxos

- cardholder -> pos: 1. apresenta cartão
- pos -> acquirer: 2. req. autorização (ISO 8583)
- acquirer -> scheme: 3. roteia para bandeira
- scheme -> issuer: 4. encaminha ao emissor
- issuer -> issuer_core: 5. verifica limite/saldo
- issuer -> scheme: 6. aprova/recusa (ms)
- scheme -> acquirer: 7. retorna autorização
- acquirer -> pos: 8. aprovado → venda OK
- acquirer -> clearing: 9. batch liquidação D+1/D+2
- clearing -> issuer: 10. débito no emissor
- clearing -> acquirer: 11. crédito no adquirente
- acquirer -> merchant: 12. repasse ao lojista (menos MDR)

## O BACEN como regulador: o que ele exige para você operar

Para um engenheiro vindo de tech, a regulação financeira parece burocracia. Na prática, ela define as *restrições de design* do sistema — e ignorá-la é o erro mais caro que uma fintech pode cometer.

**Licenciamento**: você não pode simplesmente 'abrir uma conta bancária para terceiros' ou 'emprestar dinheiro' sem autorização do BACEN. Os principais tipos de licença são: (a) **Banco Múltiplo/Comercial** — pode fazer tudo: captar depósitos, emprestar, emitir cartão, câmbio. Capital mínimo na casa de R$ 17–21 milhões (varia por carteira). (b) **Instituição de Pagamento (IP)** — pode manter contas de pagamento e emitir instrumentos (cartão pré-pago, pós-pago). Não pode emprestar com dinheiro de clientes. Capital mínimo menor. (c) **SCD (Sociedade de Crédito Direto)** — pode emprestar dinheiro próprio ou captado via CRI/CRA/debêntures. Não pode captar depósito do público. Capital mínimo R$ 1 milhão. (d) **SEP (Sociedade de Empréstimo entre Pessoas)** — marketplace de crédito (P2P lending).

**Capital mínimo e Basileia**: bancos precisam manter um índice de capital (Patrimônio de Referência / Ativos Ponderados pelo Risco) acima de um mínimo definido pelo BACEN (hoje ~10,5% + buffers). Simplificando: se você empresta R$ 100 de risco alto, precisa ter ~R$ 10,5 de capital próprio como colchão. Isso limita o crescimento da carteira de crédito.

**PLD/FT** (Prevenção à Lavagem de Dinheiro): toda IF deve ter um programa de compliance com KYC (Know Your Customer), monitoramento de transações, reporte de operações suspeitas ao COAF e treinamento de pessoal. Para o engenheiro: isso vira requisito de sistema — você precisa de pipelines de detecção de anomalias, logs imutáveis e APIs de reporte.

**SCR**: toda IF que concede crédito reporta mensalmente ao BACEN as operações de crédito de cada cliente (CPF/CNPJ). O BACEN agrega e disponibiliza esse histórico para consulta pelas IFs. É o 'banco de dados de crédito nacional' — mais completo que Serasa ou SPC porque é obrigatório.

**Compulsório**: bancos que captam depósitos são obrigados a depositar um percentual no BACEN (hoje ~20% dos depósitos à vista). Isso reduz o dinheiro disponível para empréstimos e é uma ferramenta de política monetária. Fintechs IP não captam depósitos, então não têm compulsório — mas também não podem usar o dinheiro dos clientes para emprestar.

**Reporting regulatório**: além do SCR, há dezenas de outros reportes periódicos — DLO (Demonstrativo de Limites Operacionais), COSIF (plano de contas padrão), CADOC (documentos de informações), entre outros. Um banco gasta mais tempo e dinheiro em compliance do que a maioria das fintechs imagina.

## Banco × Fintech: o que muda na prática (tabela comparativa)
| Critério | Dimensão | Banco Múltiplo / Comercial | Fintech IP (Instituição de Pagamento) | Fintech SCD (Crédito Direto) | Fintech sem licença (BaaS) |
| --- | --- | --- | --- | --- | --- |
| Licença BACEN | Banco Múltiplo / Comercial | Instituição de Pagamento | Sociedade de Crédito Direto | Nenhuma (usa licença do parceiro) | — |
| Pode captar depósito? | ✅ Sim (conta corrente, CDB, poupança) | ❌ Não (conta de pagamento ≠ depósito) | ❌ Não | ❌ Não (depende do parceiro) | — |
| Pode emprestar? | ✅ Sim (com dinheiro captado) | ❌ Não (com dinheiro de clientes) | ✅ Sim (com capital próprio / emissão) | ⚠️ Só se parceiro for SCD/banco | — |
| Capital mínimo (estimativa) | R$ 17–21 milhões+ | R$ 2–7 milhões (por modalidade) | R$ 1 milhão | Zero (custo é a taxa do BaaS) | — |
| Acesso direto ao SPI (Pix)? | ✅ Participante direto | ✅ Participante direto (se habilitado) | ⚠️ Via banco liquidante | ❌ Via parceiro | — |
| Obrigações PLD/FT | ✅ Completas (COAF, SCR, KYC…) | ✅ Completas | ✅ Completas | ⚠️ Compartilhadas com parceiro (contrato) | — |
| Compulsório | ✅ Sim (~20% depósitos à vista) | ❌ Não (não capta depósito) | ❌ Não | ❌ Não | — |
| Tempo para operar (estimativa) | 12–36 meses (processo BACEN) | 6–18 meses | 6–12 meses | Semanas (depende do parceiro BaaS) | — |
| Modelo de negócio típico | Spread de crédito + tarifas + float | MDR, tarifas de conta, interchange | Spread de crédito (capital próprio) | Produto digital sobre infraestrutura alheia | — |

## Banco × fintech: onde o BaaS resolve e onde ele limita

A tabela acima mostra os trade-offs, mas vale aprofundar a lógica arquitetural. Uma fintech que opera sobre BaaS (Banking as a Service) é análoga a uma aplicação SaaS que roda sobre um cloud provider: você ganha velocidade de go-to-market e não precisa construir a infraestrutura base, mas paga uma taxa por transação, tem limites de customização e está sujeito às políticas do parceiro.

O BaaS no Brasil funciona assim: o banco parceiro (que tem licença completa) expõe APIs para que a fintech ofereça produtos financeiros aos seus clientes. A fintech cuida da UX, do onboarding, do produto — o banco cuida da liquidação, do compulsório, do SCR e do compliance regulatório. Exemplos comuns: cartão de crédito white-label, conta de pagamento, crédito consignado via API.

O problema aparece quando a fintech quer crescer além do que o parceiro permite ou quando quer margens melhores. Nesse ponto, a decisão de obter licença própria entra em cena. Uma IP dá independência em pagamentos mas não em crédito. Uma SCD dá independência em crédito mas exige capital próprio e não permite captar depósito. Um banco completo dá tudo — mas o processo de licenciamento é longo, caro e o custo regulatório contínuo é alto.

Para o arquiteto de sistemas, a consequência prática é: o modelo de licença define quais APIs você pode expor, quais dados você precisa reportar, quais sistemas você precisa construir internamente (motor de compliance, SCR feeder, COSIF accounting) e quais você pode terceirizar. Parte 3 desta série vai detalhar exatamente esses sistemas internos.

## Por onde começar: checklist mental para o arquiteto que entra no mercado financeiro

- ✅ Primeiro, entenda QUAL trilho de pagamento o sistema usa: Pix (SPI), TED (STR), cartão (bandeira + adquirente), boleto (CIP) ou câmbio (SWIFT). Cada um tem latência, custo e regras de liquidação diferentes.
- ✅ Separe autorização de liquidação na sua cabeça — e no seu modelo de dados. São eventos distintos, em tempos distintos, com consequências distintas para consistência.
- ✅ Pergunte sempre: 'qual é a licença da empresa?' Isso define o que o sistema PODE fazer legalmente e quais obrigações de reporting existem.
- ✅ PLD/FT não é opcional e não é só um formulário — é um requisito de sistema. Você vai precisar de pipelines de monitoramento, logs imutáveis e integração com COAF.
- ✅ SCR é bidirecional: a empresa reporta crédito ao BACEN E consulta o histórico de crédito dos clientes. Projete os dois fluxos desde o início.
- ✅ No modelo de 4 partes do cartão, saiba sempre quem é o emissor e quem é o adquirente no seu contexto — os contratos, as taxas e as responsabilidades são completamente diferentes.

> **Minha visão para quem está fazendo essa transição de carreira:** Depois de 16 anos trabalhando em sistemas financeiros — incluindo infraestrutura de pagamentos de grau bancário —, a coisa que mais vejo engenheiros e arquitetos errarem ao entrar no mercado financeiro é tratar regulação como problema do time jurídico. Não é. Regulação é requisito de sistema. O BACEN não vai te ligar para pedir que você ajuste o código — ele vai multar a empresa, suspender a licença ou, no limite, intervir. Isso muda o apetite a risco de toda a organização e, portanto, as decisões de arquitetura.

O segundo erro é subestimar a complexidade dos trilhos. Pix parece simples na superfície — e a UX realmente é. Mas por baixo há ISO 20022, DICT com SLA de disponibilidade regulatório, regras de devolução, fraude em tempo real e a necessidade de liquidar reservas no BACEN. Quando você projeta um sistema de pagamentos, você está projetando contra essas restrições, não contra um banco de dados qualquer.

Minha recomendação concreta: antes de escrever uma linha de código em um projeto financeiro, leia a regulação do produto que você vai construir. Não toda — leia o normativo específico do BACEN para aquele trilho ou licença. É denso, mas é a especificação real do sistema. Tudo que você vai construir é uma implementação dessa especificação.

## Conclusão: os trilhos definem as restrições, a licença define o perímetro

O Sistema de Pagamentos Brasileiro é uma infraestrutura pública sofisticada — o Pix é genuinamente um dos melhores sistemas de pagamento instantâneo do mundo, e o BACEN merece crédito por isso. Para um arquiteto vindo de tech, a mensagem central desta aula é: cada trilho tem suas próprias regras de latência, liquidação e compliance; cada licença define o que você pode e não pode fazer; e a regulação não é burocracia — é a especificação do sistema.

A decisão banco × fintech × BaaS não é tecnológica — é estratégica e regulatória. Tecnologia executa a estratégia dentro das restrições regulatórias. Quanto mais cedo o arquiteto entender isso, melhor serão as decisões de design.

Na Parte 3 desta série, descemos mais um andar no Elevador: vamos olhar para os sistemas internos que executam tudo isso — core bancário, ledger, motor de crédito, compliance engine e a arquitetura event-driven que conecta tudo.

## Referências

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

## Fontes do caso

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