# BIAN na prática: como um banco funciona por dentro

> O mapa de serviços do BIAN 14 aplicado ao dia a dia do arquiteto: domínios, Control Records, Semantic APIs, Pix e Open Finance no mapa, o banco inteiro por dentro, do cadastro à tesouraria, e o crédito por dentro, das linhas de varejo à carteira, com técnicas, casos fictícios e IA para mapear com precisão.

_Curso gratuito de Fernando F. Azevedo · 24 aulas · ~8h_

## O que você vai saber fazer

- Ler o Service Landscape do BIAN 14 e explicar camadas, Control Record e Behavior Qualifier.
- Reconhecer padrões funcionais e action terms e ler uma Semantic API até o OpenAPI.
- Posicionar Pix, Open Finance e a regulação brasileira no mapa.
- Montar um heatmap de sistemas e desenhar fronteiras de serviço e de evento.
- Usar IA com grounding nas definições oficiais para mapear e revisar contratos, com validação e avaliação.
- Seguir o banco inteiro pelo mapa, do cadastro à cobrança, aos investimentos e ao relatório regulatório, fazendo a cada parte as três perguntas: dono do registro, padrão funcional e fato publicado.
- Ler um cenário oficial da v14 nome por nome e trocar linhas de vida obsoletas pelos substitutos anunciados.
- Aplicar técnicas de mapa, fronteira, contrato e migração à realidade de cada instituição, de banco grande a instituição de pagamento.
- Mapear o crédito de varejo de ponta a ponta: linhas, originação, rating e perda esperada, limites e grupo econômico, garantias, carteira, cobrança e regulação, com um dono por registro.

## Módulo 1: O mapa

O que é o BIAN, as camadas do landscape, Control Record, padrões funcionais e action terms.

### 01. O que é o BIAN, e o que ele não é

_Quem mantém, o que entrega e por que não é produto nem especificação de implementação._

Dois times do mesmo banco chamam a mesma coisa por nomes diferentes: um fala em 'cadastro', outro em 'onboarding', o fornecedor fala em 'party management'. Nenhum está errado, e a integração entre os três custa meses. O BIAN existe para resolver esse problema de vocabulário, e só ele. Esta aula diz quem mantém o padrão, o que ele entrega e, com a mesma ênfase, o que ele não é.

## O problema que o BIAN resolve

Pense num banco com dez anos de aquisições nas costas. O core chama a abertura de conta de 'cadastro'. O canal digital chama de 'onboarding'. O antifraude, comprado de fora, chama de 'customer due diligence'. O time de dados chama de 'party'. São quatro nomes para uma capacidade só, e cada integração começa com uma reunião para descobrir isso.

O custo aparece em três lugares.

**Integração:** cada par de sistemas negocia o próprio contrato, com o próprio dicionário, e o mapeamento entre eles vira código que alguém mantém por anos.

**Compra de software:** o RFP descreve a necessidade com palavras internas, o fornecedor responde com as dele, e a comparação entre propostas é feita no olho.

**Decisão de arquitetura:** sem um inventário de capacidades, 'temos isso duplicado?' é uma pergunta que ninguém responde sem entrevistar meia dúzia de pessoas.

O BIAN ataca a raiz: um vocabulário de capacidades bancárias mantido fora de qualquer banco e de qualquer fornecedor. Quando dois times dizem 'Party Reference Data Directory', estão falando da mesma coisa, com a mesma fronteira. Para quem programa, a analogia é uma `interface` compartilhada: ela não implementa nada, mas obriga quem implementa a concordar nos nomes.

## Quem mantém e o que entrega

O BIAN e.V. é uma associação independente e sem fins lucrativos, sediada em Frankfurt. São 113 membros: 40 bancos, 59 parceiros de software e o restante entre consultorias e instituições. Isso importa porque o padrão não pertence a um fornecedor: nenhum deles ganha quando você adota o vocabulário.

A versão corrente é a 14.0, de fevereiro de 2026. Ela traz três entregas, e cada uma serve a uma tarefa diferente do seu dia.

**Service Landscape:** o mapa. Cerca de 340 Service Domains ativos, cada um uma capacidade de negócio com fronteira definida, desenhados em ArchiMate 3.2. É o que você abre para responder 'quais capacidades este sistema cobre?' e 'onde termina Payment Order Initiation e começa Payment Settlement?'. Serve para heatmap, inventário e conversa com produto.

**Semantic APIs:** 242 contratos, com operações e payloads nomeados por Service Domain. Servem de ponto de partida para o contrato de um serviço e de língua comum com o fornecedor. O próprio BIAN avisa que os endpoints estão 'far from implementation specifications'.

**Business Object Model:** os objetos de negócio, em UML, que as APIs compartilham. É a entrega com ligação crescente com a ISO 20022, o que interessa a quem lida com mensagens de pagamento.

Há três certificações: Foundation, Banking Architecture e Data Architecture. O curso não substitui nenhuma, mas deixa você pronto para a primeira.

## As três entregas do BIAN e quem consome cada uma

O mesmo problema (uma capacidade, vários nomes) entra pelo mapa e sai como heatmap, contrato e RFP com vocabulário comum.

### 📘 BIAN e.V. (Frankfurt): três entregas da v14.0

- Service Landscape ~340 Service Domains, ArchiMate 3.2 (data)
- Semantic APIs 242 contratos, longe de implementação (compute)
- Business Object Model UML, ligação com ISO 20022 (storage)

### 👤 Quem consome

- Arquiteto mapeia e decide fronteiras (security)
- Time de produto nomeia a capacidade (frontend)
- Fornecedor alinha módulo e contrato (external)

### 📤 O que sai do mapa

- Heatmap de sistemas aula 07 (ai)
- Contrato OpenAPI aula 04 (compute)
- RFP e compra vocabulário comum (messaging)

### Fluxos

- banco -> sl: nomeia a capacidade uma vez
- sl -> api: um ou mais contratos por domínio
- bom -> api: objetos e campos compartilhados
- sl -> arq: fronteiras e inventário
- sl -> prod: nome comum da capacidade
- api -> forn: semântica do contrato
- api -> arq: ponto de partida, não produção
- arq -> heat: sistema x Service Domain
- arq -> contrato: acrescenta auth, erros, versão
- forn -> rfp: responde nas mesmas caixas
- prod -> rfp: pede nas mesmas caixas

### Vocabulário do BIAN

- **Service Landscape**: O mapa de todas as capacidades de um banco, organizado em áreas, domínios de negócio e Service Domains.
- **Service Domain**: Uma capacidade de negócio com responsabilidade única, como Current Account ou Fraud Evaluation.
- **Semantic API**: A descrição das operações de um Service Domain, publicada também em OpenAPI, ainda longe de especificação de implementação.
- **Business Object Model**: O modelo de objetos de negócio que dá forma aos dados trocados pelas APIs.
- **ArchiMate 3.2**: A linguagem de modelagem usada no landscape; o detalhe usa UML.

## O que o BIAN não é

Boa parte dos projetos de BIAN que dão errado começa com uma destas três confusões.

**Não é produto.** Não existe 'instalar o BIAN'. Um fornecedor pode vender um core cujos módulos foram nomeados segundo o landscape, o que ajuda, mas o trabalho de ler o seu banco contra o mapa continua sendo seu.

**Não é arquitetura de referência para copiar.** Os cerca de 340 Service Domains são uma decomposição funcional, não um desenho de deployment. Transformar cada domínio em um microsserviço é o erro mais caro que já vi: centenas de serviços pequenos com fronteiras que o negócio nunca pediu e um plantão que ninguém consegue cobrir. O mapa diz o que o banco faz; quantos serviços você constrói, e em que agrupamento, é decisão sua, com os seus volumes e o seu time.

**Não é especificação pronta de API.** As Semantic APIs definem semântica: nome da operação, objetos de entrada e saída. Não definem autenticação, versionamento, paginação, erros, idempotência nem limites de taxa. Quem publica a Semantic API direto como OpenAPI de produção descobre isso no primeiro incidente.

Guarde a frase do próprio BIAN sobre os endpoints: 'far from implementation specifications'. Quem escreveu o padrão não quer que você o copie. Quer que você o leia.

> **Na prática:** Na prática, uso o BIAN como uso um mapa de metrô: para saber onde estou, onde a linha termina e quais estações já existem antes de propor uma nova. O trajeto, o horário e o trem continuam sendo decisão de quem opera. Quando alguém me apresenta uma 'arquitetura alvo baseada em BIAN' com um serviço por domínio, a primeira pergunta que faço é quem acorda às 2h quando trezentos serviços falham em cascata.

## Como este curso usa o BIAN

Este curso trata o BIAN como instrumento de leitura e decisão, não como planta. Você vai usar o mapa para três coisas.

**Entender o banco:** nomear o que cada sistema faz com um vocabulário que outro arquiteto, em outro banco, reconhece. É a base do heatmap da aula 07.

**Decidir fronteiras:** quando um domínio vira um serviço, quando dois domínios moram no mesmo sistema e quando um legado cobre cinco domínios de uma vez. A aula 02 traz o Control Record, a unidade que torna essa decisão objetiva.

**Conversar com fornecedor e regulador:** Pix, Open Finance, SCR e LGPD entram no mapa nas aulas 05 e 06, para que a conversa com o Banco Central e com o fornecedor use as mesmas caixas.

Na reta final, as aulas 08 e 09 mostram o jeito IA Builder de trabalhar: a IA rascunha mapeamento e contrato com grounding nas definições oficiais, o humano decide, e tudo é medido. Nada disso funciona se a aula de hoje não ficou clara: o modelo só rascunha bem quando o vocabulário é compartilhado e estável, e é exatamente isso que o BIAN entrega.

### Checagem rápida

1. **Qual afirmação descreve melhor o BIAN?**
- [x] Um vocabulário e mapa padrão de capacidades bancárias, mantido por uma associação sem fins lucrativos, _É um padrão de referência; a implementação continua sendo sua._
- [ ] Um core bancário open source pronto para implantar, _O BIAN não entrega software._
- [ ] Uma norma do Banco Central do Brasil, _É uma associação da indústria, sem poder regulatório._
- [ ] Uma especificação de API pronta para produção, _O próprio BIAN diz que os endpoints estão longe de especificação de implementação._

## O que levar desta aula

- BIAN e.V. é associação independente e sem fins lucrativos em Frankfurt, com 113 membros (40 bancos, 59 parceiros de software). O vocabulário não pertence a nenhum fornecedor.
- Três entregas na v14.0 (fevereiro de 2026): Service Landscape com cerca de 340 Service Domains em ArchiMate 3.2, 242 Semantic APIs e o Business Object Model em UML, com ligação crescente com a ISO 20022.
- O BIAN não é produto, não é arquitetura de referência para copiar e não é especificação pronta de API. Os próprios endpoints estão 'far from implementation specifications'.
- Neste curso o mapa serve para entender o banco, decidir fronteiras e conversar com fornecedor e regulador. Um domínio não é, por padrão, um serviço.

### 02. Camadas do mapa e Control Record

_Ler o landscape de cima a baixo e entender o registro que cada domínio controla._

Abrir o Service Landscape do BIAN pela primeira vez é como abrir o mapa de metrô de uma cidade que você não conhece: centenas de caixas, duas versões do mesmo mapa e nenhuma legenda óbvia. A boa notícia é que o mapa tem só seis camadas, e dá para atravessar todas com um único exemplo: a conta corrente. Nesta aula você desce do topo até a operação de serviço e descobre por que a camada do meio, o Control Record, é a que mais responde pergunta de arquiteto.

## Seis camadas, uma conta corrente

Pense no landscape como um namespace de seis níveis. Cada nível restringe o anterior, e o exemplo da conta corrente cabe inteiro nele.

**Business Area:** a fatia mais larga do banco. Conta corrente vive em Operations and Execution, a área que executa produtos e transações no dia a dia.

**Business Domain:** um agrupamento dentro da área. Aqui é Loans and Deposits, onde moram os produtos de captação e crédito.

**Service Domain:** a unidade que importa. Current Account é um Service Domain: uma capacidade de negócio com responsabilidade única, que não se divide mais. É o nível em que você faz heatmap, atribui dono e desenha fronteira de API.

**Control Record:** o registro que o domínio controla. Para Current Account é `CurrentAccountFacility`, a conta em si com tudo que ela guarda e decide.

**Behavior Qualifier:** uma fatia do Control Record. `AmountBlock` é a fatia que trata bloqueio de valor na conta; `DebitandCredit` é a que trata lançamentos.

**Service Operation:** a ação executável sobre uma fatia. `InitiateAmountBlock` cria um bloqueio. É o que vira endpoint na Semantic API.

Se você programa, a analogia que funciona é pacote, módulo, classe, estado, atributo composto e método. Não é perfeita, mas acerta no essencial: a hierarquia não é organograma, é escopo. Cada nível responde onde uma coisa mora, e só isso. A aula 03 trata os action terms, como o `Initiate` de `InitiateAmountBlock`; aqui o objetivo é ler o caminho inteiro sem se perder.

## A pirâmide de camadas, com a conta corrente em cada nível

Do mais amplo ao mais específico. A value chain é outra estante para o mesmo Service Domain: do Current Account para baixo, nada muda.

### 🏦 Business Area (matriz: 5 áreas)

- Operations and Execution (network)

### 📂 Business Domain (matriz: 38)

- Loans and Deposits (network)

### 🧩 Service Domain

- Current Account padrão Fulfill (compute)

### 📋 Control Record

- CurrentAccountFacility Current Account + Fulfill (data)

### 🔀 Behavior Qualifiers (9 na v14, MECE)

- DebitandCredit (storage)
- AmountBlock (storage)
- +7 outros +7 others (storage)

### ⚙️ Service Operation

- InitiateAmountBlock (frontend)
- Semantic API endpoint (aula 04) (edge)

### Fluxos

- ba -> bd: contém
- bd -> sd: contém
- vc -> sd: mesmo Service Domain, outra estante
- sd -> cr: controla o ciclo de vida
- cr -> bq1: fatia
- cr -> bq2: fatia
- cr -> bq3: fatia
- bq2 -> op: expõe
- op -> api: vira endpoint

## Duas visões, os mesmos Service Domains

O BIAN publica o landscape em duas visões, e a primeira confusão de todo mundo é achar que são dois mapas. São duas estantes para os mesmos livros.

**Matriz:** cinco Business Areas (Reference Data, Sales and Service, Operations and Execution, Risk and Compliance, Business Support) e 38 Business Domains. É a visão de capacidade: agrupa pelo tipo de coisa que o domínio faz, independentemente de quem usa.

**Value chain:** oito áreas, organizadas pela sequência em que o valor é produzido. É a visão de processo: responde 'em que ponto da cadeia isso acontece'.

Current Account é o mesmo Service Domain nas duas, com o mesmo Control Record e os mesmos Behavior Qualifiers. Muda só a prateleira em que ele aparece.

Por que manter as duas? Porque arquiteto e negócio fazem perguntas diferentes. Quando eu faço heatmap de sistemas, uso a matriz: quero saber quais capacidades estão cobertas, duplicadas ou órfãs, e o agrupamento por tipo deixa isso visível. Quando preciso explicar para uma área de produto onde entra a parte dela, a value chain fala a língua do fluxo.

A regra prática: escolha uma visão por entregável e diga qual é no cabeçalho. Misturar as duas no mesmo desenho é a forma mais comum de produzir um mapa que ninguém contesta porque ninguém consegue ler.

## Control Record: o que o domínio guarda e decide

Se eu pudesse ensinar só um conceito do BIAN para um time, seria este.

Todo Service Domain segue um padrão funcional (a aula 03 lista os padrões). Current Account segue o padrão Fulfill: ele cumpre um produto contratado. O Control Record é o resultado de aplicar esse padrão a um tipo de ativo. Current Account + Fulfill = `CurrentAccountFacility`: a conta corrente como instância viva, com saldo, lançamentos, bloqueios e tudo que o domínio precisa acompanhar para cumprir o produto.

Pense nele como o agregado raiz do domínio, no sentido de DDD. É o registro cujo ciclo de vida o Service Domain controla do começo ao fim. Ninguém mais cria, altera ou encerra uma `CurrentAccountFacility` sem passar por Current Account.

É por isso que o Control Record responde a pergunta que mais trava reunião de arquitetura: quem é dono desse dado? Se o dado faz parte do Control Record de um domínio, aquele domínio é a fonte da verdade. Os outros consultam ou recebem evento. Quando dois sistemas gravam saldo de conta cada um do seu jeito, não é problema de integração, é dois donos para um Control Record.

Os Behavior Qualifiers dividem o Control Record em fatias MECE: mutuamente exclusivas e coletivamente exaustivas. Nada cai em duas fatias e nada fica de fora. Current Account tem nove na v14; `DebitandCredit` e `AmountBlock` são duas delas. Na hora de mapear um sistema legado, essa divisão vira checklist: cada fatia que o sistema não cobre é lacuna explícita, não suposição.

### Do mais amplo ao mais específico

Ordene as camadas do mapa usando o exemplo da conta corrente.

1. Operations and Execution (Business Area)
2. Loans and Deposits (Business Domain)
3. Current Account (Service Domain)
4. CurrentAccountFacility (Control Record)
5. AmountBlock (Behavior Qualifier)
6. InitiateAmountBlock (Service Operation)

## O que levar desta aula

- Seis camadas, do mais amplo ao mais específico: Business Area, Business Domain, Service Domain, Control Record, Behavior Qualifier, Service Operation.
- Matriz (5 áreas, 38 Business Domains) e value chain (8 áreas) organizam os mesmos Service Domains. Uma visão por entregável.
- Control Record = padrão funcional aplicado a um tipo de ativo. Current Account + Fulfill = CurrentAccountFacility.
- Dono do dado é o domínio cujo Control Record contém o dado. Todo o resto consulta ou recebe evento.

> **Na prática:** Na prática, eu começo todo mapeamento pelo Control Record, não pelo nome do Service Domain. Nome engana: dois times chamam de 'conta' coisas diferentes. Quando eu pergunto 'qual registro esse sistema cria, altera e encerra sozinho?', a resposta aponta o Service Domain certo em minutos, e a lista de Behavior Qualifiers diz na hora o que ele cobre e o que ele só consulta de outro lugar. Mapeamento que pula o Control Record costuma virar inventário de sistemas com rótulo BIAN colado por cima.

### Checagem rápida

1. **O que forma o Control Record de um Service Domain?**
- [x] O padrão funcional aplicado a um tipo de ativo, _Fulfill + Current Account = CurrentAccountFacility._
- [ ] A tabela principal do sistema legado, _Control Record é conceito de negócio, não de banco de dados._
- [ ] O conjunto de endpoints REST do domínio, _Endpoints operam sobre o Control Record, não o definem._
- [ ] A soma dos Behavior Qualifiers, _Os qualifiers dividem o Control Record, não o criam._

## Perguntas frequentes

### Service Domain e Control Record são a mesma coisa com dois nomes?

Não. O Service Domain é a capacidade (quem faz); o Control Record é o registro que ela controla (o que ela guarda e decide). Current Account é o domínio, CurrentAccountFacility é o registro.

### A hierarquia muda entre a matriz e a value chain?

Mudam as camadas acima do Service Domain, que é onde cada visão agrupa do seu jeito. Do Service Domain para baixo (Control Record, Behavior Qualifier, Service Operation) é idêntico nas duas.

### Posso criar um Behavior Qualifier novo para o meu banco?

Pode estender, mas antes verifique se a necessidade não cabe numa das fatias existentes. Como a divisão é MECE, um qualifier novo que sobrepõe outro quebra a regra e a interoperabilidade com quem segue o padrão. Trate extensão como exceção documentada.

### 03. Padrões funcionais e action terms

_Os 19 padrões com uma analogia do cotidiano para cada um, e os 17 verbos das operações._

Na aula anterior o Control Record ficou claro: é o objeto que um Service Domain cuida do começo ao fim. Falta a pergunta seguinte: cuida como? É isso que o padrão funcional responde em uma palavra, e é por isso que, quando abro um domínio novo, o padrão é a primeira coisa que leio. Esta aula apresenta os 19 padrões, com uma analogia do cotidiano para cada um, e os 17 verbos que aparecem em toda operação do BIAN.

## O padrão é a pista mais rápida

Um Service Domain tem nome, Control Record, operações e atributos. Dá para ler tudo isso e ainda não saber como ele se comporta. O padrão funcional resolve isso em uma palavra: ele diz qual é o ciclo de vida do Control Record. Se nasce e morre numa transação, se acumula por anos, se emite um veredito e encerra.

Pense no padrão como a classe base de que o domínio herda. Duas classes com a mesma base têm o mesmo esqueleto de operações, mesmo que uma trate de cartão e a outra de câmbio. É isso que torna o BIAN previsível para quem programa: dominou o esqueleto de Fulfill, entende qualquer domínio Fulfill em metade do tempo.

Três padrões confundem quem começa porque parecem a mesma coisa, "olhar dados". Não são. **Track** acumula lançamentos ao longo do tempo e mantém uma posição, como um extrato. **Assess** dá um veredito pontual sobre um caso e pronto, como um detector de metais. **Analyse** lê o histórico inteiro e devolve uma leitura, como a nutricionista com o diário alimentar na mão.

Se o seu sistema de fraude tem uma pontuação recalculada a cada evento e um perfil revisto por mês, você tem dois padrões diferentes e, quase sempre, dois domínios. Separar isso antes de desenhar a API poupa a refatoração que viria depois.

## Os 19 padrões funcionais, um por linha
| Padrão | Analogia do cotidiano | O que o Control Record faz |
| --- | --- | --- |
| Fulfill | Plano de academia | Cumpre um acordo ao longo do tempo até encerrar |
| Transact | Compra no caixa | Uma transação curta: começa, conclui, acaba |
| Track | Extrato | Acumula lançamentos e mantém a posição |
| Process | Emissão de fatura | Executa um procedimento em etapas até sair o resultado |
| Agree Terms | Contrato de aluguel | Negocia e mantém os termos vigentes |
| Catalog | Agenda de contatos | Mantém uma lista de referência consultável |
| Assess | Detector de metais | Avalia um caso e emite veredito pontual |
| Analyse | Nutricionista lendo o histórico | Lê o histórico e devolve uma leitura |
| Monitor | Termômetro | Observa um sinal contínuo e alerta no desvio |
| Operate | Catraca | Opera um recurso em uso contínuo |

## Quando o padrão muda, o domínio muda

O padrão não é rótulo decorativo. Ele define que operações existem e que estado o Control Record carrega. Por isso trocar o padrão é uma mudança real, não cosmética.

Na v14 alguns domínios mudaram de padrão. O exemplo mais limpo é **Legal Advisory**, que saiu de Fulfill para Advise. A leitura é direta: antes o domínio era modelado como quem cumpre um acordo de prestação de serviço jurídico, agora é modelado como quem responde a uma consulta. O Control Record deixa de ser um arranjo de serviço e passa a ser uma sessão de aconselhamento, e as operações seguem essa troca.

No mapeamento isso tem um uso prático. Quando um sistema seu "não cabe" no domínio que parecia óbvio, teste o padrão antes de inventar domínio novo. Pergunte: o que o meu sistema guarda, acumula, encerra ou emite? Se acumula, procure um Track. Se emite veredito, um Assess. Se mantém um acordo vivo, um Fulfill ou um Agree Terms. Na maioria das vezes o domínio aparece, e o que parecia lacuna era só padrão errado.

Vale também para avaliar o que uma IA propõe: um mapeamento que coloca um sistema de posição de saldo num domínio Assess está errado pelo padrão, antes de qualquer discussão sobre nome. A aula 08 volta a isso com grounding nas definições oficiais.

> **Na prática:** Quando recebo um inventário de sistemas para mapear, a primeira coluna que preencho é o padrão, não o domínio. Padrão se decide olhando o banco de dados do sistema: tabela que só cresce é Track, tabela de casos com status final é Assess, tabela de contratos com vigência é Agree Terms ou Fulfill. Com o padrão certo, a lista de domínios candidatos cai de dezenas para um punhado, e a discussão com o time vira "qual destes" em vez de "onde isso entra".

### Domínio e padrão funcional (v14)

- **Current Account** → Fulfill
- **Payment Order Initiation** → Transact
- **Position Keeping** → Track
- **Fraud Evaluation** → Assess
- **Fraud Diagnosis** → Analyse
- **Payment Rail** → Operate
- **Issued Device Administration** → Allocate
- **Customer Billing** → Process
- **Party Reference Data Directory** → Catalog
- **Customer Agreement** → Agree Terms

## Os 17 action terms em quatro famílias

Toda operação de um Service Domain é um action term aplicado a uma parte do Control Record: `Initiate` abre, `Update` altera, `Retrieve` lê. São 17 verbos, organizados em quatro famílias conforme o que tocam.

**Governar o domínio:** `Activate`, `Configure` e `Feedback`. Não mexem em registro nenhum. Ligam o domínio, ajustam parâmetros e recebem retorno sobre o serviço. É o painel de administração, não a transação.

**Criar registro:** `Initiate`, `Create`, `Register`, `Evaluate` e `Provide`. Cada um abre uma instância nova do Control Record. O verbo muda com o padrão: um domínio Fulfill inicia, um Catalog registra, um Assess avalia. Mesmo efeito, nasce um registro, verbo escolhido pelo ciclo de vida.

**Agir sobre registro:** `Update`, `Control`, `Exchange`, `Capture`, `Execute`, `Request` e `Grant`. Alteram um registro que já existe. `Control` suspende e retoma, `Exchange` aceita ou rejeita, `Capture` grava um evento vindo de fora, `Execute` roda uma etapa, `Request` pede uma ação, `Grant` concede.

**Ler sem alterar:** `Retrieve` e `Notify`. Devolvem estado ou avisam que algo mudou, sem mudar nada. O guia do BIAN cita CQRS ao separar leitura de escrita; para quem já separa command de query, é a mesma ideia levada à borda do serviço. Na implementação isso significa que `Retrieve` pode ser servido pela réplica de leitura e os outros quinze ficam no caminho transacional. Decidir isso cedo evita que a API de consulta herde o lock da API de escrita.

## Quatro famílias de action terms em volta do Control Record

Três verbos governam o domínio sem tocar em registro; cinco criam uma instância; sete alteram uma instância existente; dois leem ou avisam sem alterar nada, o lado de consulta do CQRS.

### ⚙️ Governar o domínio

- Activate · Configure · Feedback liga e parametriza o serviço (security)

### 🏦 Service Domain

- Configuração do domínio parâmetros do serviço (compute)
- Control Record instância com ciclo de vida do padrão (data)

### 🆕 Criar registro

- Initiate · Create · Register Evaluate · Provide (compute)

### ✏️ Agir sobre registro

- Update · Control · Exchange Capture (messaging)
- Execute · Request · Grant altera estado existente (messaging)

### 🔎 Ler sem alterar

- Retrieve devolve o estado atual (data)
- Notify avisa que algo mudou (data)

### Fluxos

- consumer -> govern: administração
- govern -> domain: ajusta o serviço, não o registro
- consumer -> create: abre uma instância
- create -> cr: nasce o registro
- consumer -> act-a: altera
- consumer -> act-b: altera
- act-a -> cr: muda estado
- act-b -> cr: muda estado
- cr -> retrieve: leitura, pode vir da réplica
- cr -> notify: evento de mudança
- retrieve -> consumer: estado
- notify -> consumer: aviso

## O que levar desta aula

- O padrão funcional é o ciclo de vida do Control Record em uma palavra: leia-o antes do nome do domínio.
- Track acumula, Assess dá veredito pontual, Analyse lê o histórico. Parecem iguais e são três padrões diferentes.
- Troca de padrão é mudança real: Legal Advisory saiu de Fulfill para Advise na v14 e o Control Record mudou junto.
- Os 17 action terms se dividem em governar o domínio, criar registro, agir sobre registro e ler sem alterar.
- Retrieve e Notify são o lado de consulta; o guia do BIAN cita CQRS, e isso autoriza réplica de leitura desde o desenho.

### Action terms por família

- **Governar o domínio**: Activate, Configure, Feedback
- **Criar um registro**: Initiate, Create, Register, Evaluate, Provide
- **Agir sobre um registro**: Update, Control, Exchange, Capture, Execute, Request, Grant
- **Ler sem alterar**: Retrieve, Notify

## Perguntas que aparecem nesta altura

### Todo Service Domain expõe os 17 verbos?

Não. Cada padrão usa o subconjunto que faz sentido para o seu ciclo de vida: um Catalog registra e consulta, um Fulfill inicia, atualiza, controla e consulta. A lista exata por padrão não é tema desta aula; na aula 04 você vê isso lendo um domínio até o OpenAPI.

### Posso criar um action term próprio quando nenhum dos 17 serve?

Quase sempre o verbo que falta é um dos 17 mal escolhido, ou um sinal de que a operação pertence a outro domínio. Antes de inventar, pergunte se você está criando, alterando ou lendo um registro e se o registro é mesmo deste Control Record. Verbo fora do vocabulário quebra a previsibilidade que é o motivo de usar BIAN.

## Módulo 2: Do domínio à regulação

Da Semantic API ao OpenAPI, o Pix no mapa e a regulação brasileira no lugar certo.

### 04. Lendo um Service Domain até o OpenAPI

_O caminho de cada endpoint, o mapeamento para HTTP e o que fica para a sua implementação._

Abrir um YAML do BIAN pela primeira vez dá a sensação de que a API já está pronta: caminho, método, schema, tudo ali. Não está. O que o BIAN publica é o contrato semântico; quem decide autenticação, idempotência, versão e modelo de erro é você. Esta aula ensina a ler um Service Domain até o OpenAPI sabendo exatamente onde a especificação termina e onde a sua implementação começa.

## A anatomia do caminho

Todo endpoint dos YAMLs da v14 tem a mesma forma:

`/{ServiceDomain}/{crId}/{BehaviorQualifier}/{bqId}/{ActionTerm}`

Cada segmento aponta para uma camada do mapa que você viu na aula 02. O primeiro é o Service Domain. O segundo identifica uma instância do Control Record. O terceiro é o Behavior Qualifier, a parte do Control Record que a operação toca. O quarto identifica uma instância desse qualifier. O quinto é o action term da aula 03: o verbo.

Pegue o Current Account na v14 como referência. Ele segue o padrão funcional Fulfill, o Control Record se chama `CurrentAccountFacility`, a especificação lista 34 operações e 9 Behavior Qualifiers, e o nome proposto no alinhamento com ISO 20022 é `CashAccountService`. Quando você lê `/CurrentAccount/{id}/...`, está lendo: um domínio, uma conta, uma faceta dessa conta, um evento nessa faceta, uma ação.

**O que o caminho não carrega:** tenant, canal, versão, ambiente. Nada disso está no YAML, e é de propósito. O BIAN descreve o que o banco faz, não como a sua empresa publica isso. Guarde essa frase: ela explica tudo o que vem no fim da aula.

A leitura que recomendo: trate o caminho como o mapa dobrado numa URL. Se um segmento não corresponde a uma camada do mapa, ou você leu errado ou alguém inventou um segmento.

## Cada segmento do caminho aponta para uma camada do mapa

Exemplo real da v14: PUT /CurrentAccount/{crId}/DebitandCredit/{bqId}/Execute. Os cinco segmentos vêm do BIAN; o que está no grupo de baixo é responsabilidade sua.

### 🔗 URL: os cinco segmentos

- /CurrentAccount (edge)
- /{crId} uma conta (edge)
- /DebitandCredit (edge)
- /{bqId} um movimento (edge)
- /Execute (edge)

### 🗺️ BIAN: camadas do mapa

- Service Domain Current Account (Fulfill) (compute)
- Control Record CurrentAccountFacility (data)
- Behavior Qualifier 1 de 9 (data)
- Action Term Execute (messaging)

### 🧩 Sua implementação

- Método HTTP YAML v14: PUT (frontend)
- Auth, Idempotency-Key, versão, erro, SLO (security)

### Fluxos

- seg-sd -> sd: nomeia
- seg-cr -> cr: instância
- seg-bq -> bq: faceta do CR
- seg-bqid -> bq: instância
- seg-at -> at: verbo
- at -> http: mapeamento fixo
- http -> yours: BIAN não decide

## Lendo /CurrentAccount/{id}/DebitandCredit/{id}/Execute segmento a segmento

1. **/CurrentAccount**: O Service Domain. Padrão Fulfill: ele cumpre um produto já contratado. Na leitura DDD, é o bounded context candidato.

2. **/{id} (primeiro)**: O crId: uma instância de CurrentAccountFacility, ou seja, uma conta específica. Tudo depois deste segmento acontece dentro dessa conta.

3. **/DebitandCredit**: O Behavior Qualifier, um dos 9 do Current Account. É a faceta do Control Record que trata lançamentos de débito e crédito.

4. **/{id} (segundo)**: O bqId: um lançamento específico dentro daquela conta. Não é um agregado próprio; vive dentro do Control Record.

5. **/Execute**: O action term. Nos YAMLs da v14 vira PUT. Executar um lançamento é a ação que move dinheiro, e é exatamente aqui que idempotência deixa de ser detalhe.

## Do action term ao método HTTP, e os quatro sabores

O mapeamento nos YAMLs da v14 é fixo e vale a pena decorar: **Retrieve vira GET**, **Initiate vira POST**, e **Update, Execute e Exchange viram PUT**. A lógica é a do HTTP: Initiate cria uma instância (POST), Retrieve lê (GET), e os três últimos agem sobre uma instância que o caminho já identifica (PUT).

Essa escolha tem uma consequência que o YAML não discute. PUT, pela semântica do HTTP, é idempotente: repetir a chamada deveria dar o mesmo resultado. Um Execute de débito repetido não é naturalmente idempotente. Então o BIAN entrega um método que promete idempotência e você precisa cumprir a promessa, com chave de idempotência e armazenamento do resultado. Isso volta no bloco final.

**Os quatro sabores de publicação.** A mesma semântica sai em quatro formas: REST ou assíncrona, cada uma com o Business Object Model do próprio BIAN ou com mensagens ISO 20022. São dois eixos, não quatro padrões diferentes. O que muda é o transporte e o vocabulário dos payloads; o que não muda é o Service Domain, o Control Record e o action term.

Minha regra: REST com Business Object Model quando a API é interna e consumida por times de produto; ISO 20022 quando a mensagem atravessa a fronteira do banco para trilho ou parceiro, que é o caso do Pix na aula 05. Assíncrono quando a operação não cabe no tempo de uma requisição ou quando o consumidor precisa de evento, não de resposta.

### Leia o caminho

1. **Em /CurrentAccount/{id}/DebitandCredit/{id}/Execute, o que é DebitandCredit?**
- [x] Um Behavior Qualifier do Control Record da conta, _Fica entre o id do Control Record e o id do qualifier._
- [ ] Um Service Domain, _O Service Domain é CurrentAccount, o primeiro segmento._
- [ ] Um action term, _O action term é Execute, o último segmento._
- [ ] Um padrão funcional, _O padrão (Fulfill) não aparece no caminho._

2. **Que método HTTP o Execute usa nos YAMLs v14?**
- [x] PUT, _Update, Execute e Exchange viram PUT._
- [ ] GET, _GET é do Retrieve._
- [ ] POST, _POST é do Initiate._
- [ ] DELETE, _Não é o mapeamento usado pelo BIAN para Execute._

## Action term x método HTTP nos YAMLs da v14
| Action term | Método HTTP | O que faz | O que fica com você |
| --- | --- | --- | --- |
| Retrieve | GET | Lê uma instância do Control Record ou do Behavior Qualifier | Paginação, filtros e cache; o YAML não os define |
| Initiate | POST | Cria uma nova instância | Idempotência de criação e geração do id |
| Update | PUT | Altera uma instância existente | Controle de concorrência e auditoria da mudança |
| Execute | PUT | Executa a ação de negócio na instância | Idempotency-Key obrigatória; é onde o dinheiro se move |
| Exchange | PUT | Aceita, rejeita ou responde a uma instância | Autorização por papel: quem pode aceitar o quê |

## Leitura DDD e o que fica com você

Se você vem de Domain-Driven Design, a tradução é curta. O **Service Domain é um bounded context candidato**. Candidato, não decreto: a aula 07 mostra que um Service Domain pode virar dois sistemas e três Service Domains podem morar num só. O **Control Record é o aggregate**: a fronteira de consistência. O Behavior Qualifier vive dentro dele, por isso `DebitandCredit/{id}` não é um agregado separado, é uma entidade dentro de `CurrentAccountFacility`.

Essa leitura resolve uma dúvida frequente: "posso ter uma transação que toca dois Control Records?". Pode, mas ela atravessa dois agregados, e isso é saga ou orquestração, não uma chamada só. O caminho do BIAN deixa isso visível: cada URL toca um crId.

Agora a lista do que o YAML não resolve e que é sua responsabilidade escrever no OpenAPI que vai para o gateway:

- **Autenticação:** o esquema de segurança (OAuth 2, mTLS) não está no YAML.
- **Autorização:** quem pode chamar Execute em qual conta. Isso é regra de negócio e de regulação.
- **Idempotência:** chave por chamada em Initiate e Execute, com resultado armazenado.
- **Versionamento:** no caminho ou no header, mas em algum lugar, porque a v14 não põe versão na URL.
- **Modelo de erro:** um formato único para todos os domínios; `problem+json` é a minha escolha padrão.
- **Paginação:** Retrieve de coleções precisa de cursor ou offset.
- **SLO:** latência e disponibilidade por operação, porque Retrieve e Execute não têm o mesmo custo de falha.

A analogia para quem programa: o BIAN entrega a interface; a classe que implementa é sua.

> **Na prática:** Na prática, eu uso o YAML do BIAN como gabarito de nomes e de fronteira, nunca como o arquivo que vai para o gateway. Copio o caminho, mantenho o action term e o método, e escrevo o meu OpenAPI por cima: security scheme, header de idempotência, versão e um único modelo de erro. Time que publica o YAML cru acaba com um modelo de erro por domínio e sem resposta para "quem pode chamar Execute". O custo não aparece na primeira entrega; aparece na auditoria.

## O que levar desta aula

- Todo caminho da v14 é /{ServiceDomain}/{crId}/{BehaviorQualifier}/{bqId}/{ActionTerm}, e cada segmento é uma camada do mapa.
- Retrieve é GET, Initiate é POST, Update, Execute e Exchange são PUT; PUT promete idempotência e você cumpre a promessa.
- Quatro sabores em dois eixos: REST ou assíncrono, Business Object Model ou ISO 20022. A semântica não muda.
- Service Domain é bounded context candidato; Control Record é o aggregate; o Behavior Qualifier vive dentro dele.
- Autenticação, autorização, idempotência, versão, erro, paginação e SLO não estão no YAML. São seus.

### 05. Pix no mapa do BIAN

_Um Pix de R$ 50 às 23h atravessando os Service Domains da v14._

São 23h e alguém paga R$ 50 pelo celular. Em poucos segundos o dinheiro sai de uma conta e aparece em outra, num banco diferente. Por trás desse gesto, nove Service Domains do BIAN 14 mudam de estado, e dois sistemas externos, o DICT e o SPI, entram na conversa. Esta aula segue esses R$ 50 passo a passo.

## A jornada em nove domínios

O BIAN 14 traz um cenário oficial chamado External Credit Transfer: uma transferência de crédito em que o dinheiro sai do seu banco e chega a uma conta em outra instituição. Pix é exatamente isso, só que em tempo real. Vou usar esse cenário como base e contar a história na ordem em que os domínios entram.

**Payment Order Initiation:** o cliente abre o app, informa a chave e os R$ 50. Nasce aqui a ordem de pagamento, com seu próprio Control Record.

**Payee Management:** antes de pagar, o banco precisa saber quem recebe. A chave Pix vira conta, agência e instituição. Como o DICT é operado pelo Banco Central, este domínio funciona como uma fachada: ele guarda a resolução, mas a fonte da verdade é externa.

**Payment Orchestration:** coordena os próximos passos e sabe em que ponto a ordem está.

**Payment Confirmation:** checa se a ordem pode seguir. Para pessoa física, o exemplo clássico é o limite noturno de R$ 1.000 após as 20h: às 23h, R$ 50 passam; R$ 1.500 não.

**Fraud Evaluation:** dá o veredito de fraude sobre a ordem.

**Payment Rail:** conversa com o trilho externo, o SPI, no formato que ele entende.

**Payment Settlement:** registra a liquidação confirmada pelo trilho.

**Current Account:** debita os R$ 50 na conta do pagador.

**Position Keeping:** registra a posição resultante para o financeiro do banco.

Se você lê artigos antigos e encontra Payment Execution, Payment Order ou Payment Instruction, pare: esses três domínios estão obsoletos na v14. O mapa acima é o atual.

## Um Pix de R$ 50 às 23h pelos nove domínios da v14

Fluxo da ordem dentro do banco pagador, com o DICT e o SPI como sistemas externos operados pelo Banco Central.

### 🏦 Banco pagador: ordem e recebedor

- Payment Order Initiation ordem nasce aqui (frontend)
- Payee Management fachada do DICT (compute)
- Payment Orchestration coordena os passos (compute)

### 🔐 Banco pagador: controles

- Payment Confirmation limite noturno R$ 1.000 (security)
- Fraud Evaluation veredito de fraude (security)

### 📡 Banco pagador: trilho e liquidação

- Payment Rail fala ISO 20022 (messaging)
- Payment Settlement liquidação confirmada (data)

### 📒 Banco pagador: contas e posição

- Current Account débito de R$ 50 (storage)
- Position Keeping posição registrada (storage)

### 🌐 Banco Central: sistemas externos

- DICT diretório de chaves (external)
- SPI liquidação bruta em tempo real (external)

### Fluxos

- cliente -> poi: 1. chave + R$ 50
- poi -> orch: 2. ordem criada
- orch -> payee: 3. resolver recebedor
- payee -> dict: consulta a chave
- orch -> conf: 4. checar limites
- orch -> fraud: 5. veredito
- orch -> rail: 6. enviar ao trilho
- rail -> spi: pacs.008
- spi -> rail: pacs.002 (status)
- rail -> settle: 7. liquidado
- settle -> ca: 8. debitar conta
- ca -> pk: 9. registrar posição

## Por que o mapa ajuda: cada passo tem dono

A pergunta útil não é "o Pix funciona?", é "quando ele falha às 23h, quem é o dono do passo que falhou?". É aqui que o mapa paga a conta.

Cada domínio da jornada tem um Control Record próprio, aquele registro que vimos na aula 02. A ordem vive em Payment Order Initiation. A resolução da chave vive em Payee Management. O estado da coordenação vive em Payment Orchestration. O veredito vive em Fraud Evaluation. Nenhum deles precisa olhar dentro do outro: cada um expõe o seu estado pela Semantic API e pronto.

Pense em um pipeline de deploy. Você não grava o resultado do teste dentro do artefato de build; cada etapa tem seu log e seu status. Se o deploy quebra, você sabe em qual etapa olhar. A jornada do Pix é a mesma ideia aplicada a dinheiro.

O que isso muda na operação:

- **Incidente:** "o Pix não caiu" vira "a ordem foi aceita, a chave resolveu, o trilho devolveu `pacs.002` de rejeição". Cada frase aponta um domínio.
- **Fronteira de sistema:** quando dois times discutem quem implementa o limite noturno, a resposta está no mapa: Payment Confirmation.
- **Auditoria:** cada decisão tem registro próprio, com dono. Não existe uma "tabela de pagamentos" gigante onde tudo se mistura.

O custo de manter isso não é o de desenhar o mapa, é o de respeitar a fronteira todos os dias. Um atalho que grava saldo dentro do orquestrador parece inofensivo no sprint e vira dívida permanente em dois anos.

> **Na prática:** Na prática, o erro que mais vejo em mapeamentos de Pix é colocar o DICT "dentro" de Payee Management, como se o banco fosse dono da chave. Não é. Modele a fachada como fachada: cache com validade, chamada externa explícita e registro de quem consultou o quê. Quando o Banco Central mudar uma regra do DICT, você quer saber em um lugar só onde isso bate.

### A jornada do Pix de R$ 50 às 23h

Ordene os domínios do pedido do cliente até o registro da posição.

1. Payment Order Initiation
2. Payee Management
3. Payment Orchestration
4. Payment Confirmation
5. Fraud Evaluation
6. Payment Rail
7. Payment Settlement
8. Current Account
9. Position Keeping

## O que é Brasil e o que é igual no mundo

Dois sistemas da história são externos ao banco e são brasileiros: o DICT e o SPI, ambos operados pelo Banco Central.

O DICT é o diretório de chaves. Em muitos países, o equivalente a uma chave Pix fica dentro de cada banco ou num consórcio privado. Aqui, a chave resolve numa fonte central. Por isso Payee Management vira fachada: ele cuida de cache, auditoria e política de uso, mas quem responde "quem é o dono desta chave" é o DICT.

O SPI é o trilho. Segundo o Banco Central, ele faz liquidação bruta em tempo real, transação por transação, e as Contas PI dos participantes não podem ficar com saldo negativo. Isso define o comportamento de Payment Rail e de Payment Settlement: não existe "lote da noite" para compensar depois. Cada Pix liquida sozinho, ou é rejeitado.

As mensagens seguem ISO 20022, e três delas bastam para entender o fluxo:

- `pacs.008`: o pagamento em si, enviado pelo banco pagador.
- `pacs.002`: o status, dizendo se o trilho aceitou ou rejeitou.
- `pacs.004`: a devolução, quando o dinheiro precisa voltar.

E o que é igual em qualquer pagamento instantâneo do mundo? A jornada dos nove domínios. Iniciar, resolver o recebedor, orquestrar, confirmar limites, avaliar fraude, falar com o trilho, liquidar, debitar e registrar posição: esse esqueleto não muda. Muda o trilho, muda o diretório, mudam os limites regulatórios. Se você mapear um sistema de pagamentos fora do Brasil, troque os nós externos do diagrama e mantenha o resto.

## O que levar desta aula

- O cenário base é o External Credit Transfer da v14; Pix é uma instância em tempo real dele.
- Nove domínios, nove donos, nove Control Records: ninguém grava estado dentro do vizinho.
- Payee Management é fachada do DICT; Payment Rail é quem fala `pacs.008`, `pacs.002` e `pacs.004` com o SPI.
- Liquidação bruta em tempo real e Conta PI sem saldo negativo tiram o lote noturno do desenho.
- Payment Execution, Payment Order e Payment Instruction estão obsoletos na v14. Se o artigo usa esses nomes, ele é antigo.

### Checagem rápida

1. **Qual destes nomes NÃO deve aparecer num mapeamento para a v14?**
- [x] Payment Execution, _Obsoleto na v14; Payment Settlement é o substituto anunciado._
- [ ] Payment Orchestration, _É novo na v14._
- [ ] Payee Management, _É novo na v14._
- [ ] Payment Rail, _É o nome atual (antes Payment Rail Operations)._

## Dúvidas frequentes

### O limite noturno de R$ 1.000 é regra do BIAN?

Não. O BIAN diz onde a checagem mora (Payment Confirmation), não qual é o valor. O limite é contexto regulatório brasileiro e é usado aqui só como exemplo de regra que vive nesse domínio.

### E a devolução, onde entra no mapa?

Esta aula não cobre o fluxo completo de devolução. O que importa saber: ela chega como `pacs.004` pelo trilho e passa pelos mesmos donos, Payment Rail, Payment Settlement, Current Account e Position Keeping, agora com crédito em vez de débito.

### Posso simplificar e juntar Orchestration com Confirmation num serviço só?

Pode implementar os dois no mesmo deploy, se o time é um só. O que não pode é misturar os Control Records: o estado da coordenação e a decisão de limite têm ciclos de vida e auditoria diferentes. Fronteira lógica fica; fronteira de deploy é escolha sua.

### 06. Open Finance, SCR, LGPD e Banco Central no mapa

_O que da regulação vira domínio e o que vira restrição de implantação._

Toda norma nova chega à mesa do arquiteto com a mesma pergunta: "onde isso entra no sistema?". A pergunta certa é outra: essa regra cria uma responsabilidade de negócio com ciclo de vida próprio, ou só muda onde e como o que já existe pode rodar? A primeira vira Service Domain no mapa. A segunda vira restrição de implantação. Confundir as duas é como modelar "estar em conformidade" como um microsserviço.

## O teste das duas perguntas

Na aula 02 você viu que um Service Domain existe porque tem um Control Record: uma instância de negócio que nasce, muda de estado e é consultada. É esse o teste que eu aplico a cada norma.

**Primeira pergunta: a regra cria algo que precisa ser instanciado e acompanhado?** Um consentimento tem início, finalidade, prazo e revogação. Uma remessa regulatória tem período, conteúdo, envio e aceite. Isso é Control Record, logo é domínio, e quase sempre o BIAN já tem um com esse nome.

**Segunda pergunta: a regra muda como algo existente opera, sem criar instância nova?** Exigir que o dado fique numa região, que o fornecedor de nuvem tenha contrato com cláusulas específicas, que exista plano de saída. Nada disso é um objeto de negócio. É restrição que se aplica a todos os domínios ao mesmo tempo, no nível da implantação.

Existe um terceiro caso, mais sutil: a regra não cria domínio nem é só infraestrutura, ela muda o comportamento de um domínio que já existe. O direito à revisão de decisão automatizada é o exemplo clássico, e volto nele adiante.

A regra prática: se você consegue escrever "um X foi criado para o cliente Y em Z", X é candidato a domínio. Se a frase sai "o sistema precisa ser Z", é restrição.

## Open Finance: o consentimento tem ciclo de vida

A Resolução Conjunta nº 1/2020 define o consentimento do Open Finance como livre, informado, prévio e inequívoco, com finalidade determinada e revogável a qualquer tempo. Leia essa frase como engenheiro: cada adjetivo é um estado ou uma validação.

**Prévio** significa que nenhum dado sai antes de o registro existir. **Finalidade determinada** significa que o registro carrega escopo, e a consulta precisa checar o escopo, não só a existência. **Revogável a qualquer tempo** significa que o estado muda por iniciativa do cliente, a qualquer hora, e tudo que depende dele precisa reagir.

Isso é a descrição de um Control Record. Na versão 14 ele ganhou domínio próprio: **Customer Consent**. Antes, cada banco espalhava consentimento entre cadastro, canais e API gateway, e revogação virava uma caça ao tesouro.

Ao redor dele entram dois vizinhos. **Party Authentication** prova quem está consentindo. Para a iniciação de pagamento, o pedido autorizado vira ordem em **Payment Order Initiation**, o mesmo domínio que você viu no Pix na aula 05: o Open Finance não cria um "pagamento diferente", cria uma origem diferente para a mesma ordem.

A escala muda a conversa. Em maio de 2026 havia cerca de 116 milhões de autorizações de compartilhamento ativas. Com esse volume, revogação não é exceção que se trata na mão: é fluxo de primeira classe, com evento, consumidor e prazo de propagação medido.

## A regulação em duas colunas: o que vira domínio e o que vira restrição

Cada norma brasileira ligada ao Service Domain que a absorve. À esquerda, regras que criam um Control Record. À direita, regras que mudam como um domínio existente opera ou onde ele pode rodar.

### 📜 Regulação: vira domínio

- Res. Conjunta 1/2020 consentimento Open Finance (external)
- Res. CMN 5.037/2022 SCR (external)
- MED devolução no Pix (external)

### 🔒 Regulação: vira restrição

- LGPD art. 20 revisão de decisão automatizada (security)
- Res. CMN 4.893/2021 alterada pela 5.274/2025 (security)

### 🧩 BIAN 14: Service Domains

- Customer Consent novo na v14 (data)
- Party Authentication (security)
- Payment Order Initiation (compute)
- Regulatory Reporting (data)
- Fraud Resolution (compute)
- Customer Case (frontend)
- Domínios Assess / Analyse ex.: Customer Credit Rating (ai)

### ☁️ Implantação: onde e como roda

- Nuvem, região, contrato, plano de saída (network)

### Fluxos

- res1 -> consent: ciclo de vida do consentimento
- res1 -> auth: quem consente
- res1 -> poi: iniciação de pagamento
- scr -> regrep: remessa e consulta
- med -> fraud: composição
- med -> case: composição
- lgpd -> assess: requisito: caminho de revisão humana
- assess -> case: pedido de revisão
- r4893 -> deploy: restringe todos os domínios

## SCR e LGPD art. 20: remessa é domínio, revisão é requisito

O SCR, Sistema de Informações de Crédito, é regido pela Resolução CMN 5.037/2022. O banco remete ao Banco Central as operações de crédito dos seus clientes e consulta o histórico que outras instituições enviaram. No mapa isso não ganha domínio novo: entra em **Regulatory Reporting**, que já existe para toda remessa ao regulador. A remessa é a instância: período, conteúdo, envio, aceite ou rejeição. O que muda é a configuração, não a caixa.

A LGPD é o terceiro caso do teste. O art. 20 dá ao titular o direito de pedir revisão de decisão tomada só com base em tratamento automatizado. Nenhum domínio novo nasce daí. O que nasce é um requisito dentro dos domínios de padrão Assess e Analyse que decidem sobre a pessoa: avaliação de crédito, avaliação de fraude, qualquer caixa cujo action term devolve um veredito sobre alguém.

Na prática o requisito tem três partes: a decisão precisa guardar o que a produziu (versão do modelo, variáveis, limiar), precisa existir um caminho de revisão humana, e esse caminho precisa estar ligado ao atendimento, que no BIAN é **Customer Case**. Se o seu modelo de crédito decide em 200 ms e ninguém consegue reconstruir por quê, você tem um Service Domain funcionando e uma obrigação legal descoberta.

Esse ponto volta com força na aula 09, quando o avaliador for um agente e não um modelo de score.

### Regulação e lugar no mapa

- **Consentimento do Open Finance** → Customer Consent
- **DICT** → Payee Management (fachada para a fonte externa)
- **SCR** → Regulatory Reporting
- **LGPD art. 20** → Requisito nos domínios que decidem (Assess, Analyse)
- **Resolução CMN 4.893** → Restrição de implantação, não domínio
- **MED** → Composição: Fraud Resolution + Customer Case

## 4.893, nuvem e o que o Brasil tem de diferente

A Resolução CMN 4.893/2021, sobre segurança cibernética e contratação de serviços de nuvem, segue em vigor, alterada pela 5.274/2025. Aplique o teste: ela não cria nenhuma instância de negócio. Ela diz como o que já existe pode ser contratado, onde pode rodar e o que precisa estar documentado e comunicado. No mapa, portanto, não é domínio: é restrição de implantação que pesa sobre todos os domínios ao mesmo tempo. O lugar dela é no heatmap da aula 07, como atributo de cada sistema, não como caixa.

Onde o Brasil é igual ao mundo e onde não é? O mapa de domínios é o mesmo: consentimento, autenticação, ordem de pagamento e remessa regulatória existem em qualquer país. O que muda é quem opera o quê e quais composições existem.

**O DICT é central**, operado pelo Banco Central. O banco não tem um "domínio de diretório" próprio; ele consome um diretório externo e precisa modelar essa dependência como parceiro, não como caixa interna.

**O MED não tem domínio próprio.** O Mecanismo Especial de Devolução é um procedimento com prazos e papéis definidos, mas no BIAN ele vira composição: **Fraud Resolution** conduz a investigação e a devolução, **Customer Case** registra a contestação do cliente. Quem cria um "MED Service Domain" está duplicando dois domínios que já existem e vai pagar a manutenção em dobro.

> **Na prática:** O erro que mais vi em mapeamentos foi tratar norma como caixa. Alguém cria um domínio "LGPD" ou "Compliance" e, seis meses depois, ele virou o lugar onde todo requisito mal entendido vai parar. Minha regra: só crio domínio quando consigo nomear o Control Record. Se o nome que sai é o número da resolução, não é domínio, é restrição ou requisito dentro de um domínio que já existe.

## O que levar desta aula

- Norma vira domínio quando cria uma instância de negócio com ciclo de vida; vira restrição quando muda onde e como o existente roda.
- Consentimento do Open Finance (Resolução Conjunta nº 1/2020) é Control Record de Customer Consent, com Party Authentication ao lado e Payment Order Initiation para iniciação de pagamento.
- SCR (Resolução CMN 5.037/2022) é configuração de Regulatory Reporting, não domínio novo.
- LGPD art. 20 é requisito dentro dos domínios Assess e Analyse que decidem sobre a pessoa: rastro da decisão, revisão humana e ligação com Customer Case.
- Resolução CMN 4.893/2021 (alterada pela 5.274/2025) é restrição de implantação sobre todos os domínios, e mora no heatmap, não no mapa.
- DICT é diretório central do Banco Central, modelado como dependência externa; MED é composição de Fraud Resolution + Customer Case.

## Perguntas que aparecem no mapeamento

### O Open Finance precisa de um domínio de "compartilhamento de dados"?

Não. O dado compartilhado pertence ao domínio que já é dono dele (uma conta, um cartão, um empréstimo) e sai pelo action term de consulta desse domínio. O que o Open Finance acrescenta é a verificação de Customer Consent antes de responder e a autenticação em Party Authentication. Um domínio de "compartilhamento" só duplicaria dados que já têm dono.

### O mesmo teste vale para regulação fora do Brasil?

Vale, porque o teste é sobre Control Record, não sobre país. O que muda é a resposta: cada jurisdição decide o que é central e o que fica no banco, como o DICT mostra. Os detalhes das normas estrangeiras não são cobertos neste curso.

## Módulo 3: O BIAN no trabalho

Heatmap, fronteiras, erros clássicos, mapeamento com IA e agentes com fronteira de domínio.

### 07. Heatmap, fronteiras e erros clássicos

_Usar o mapa para decidir manter, comprar, construir ou aposentar, e para desenhar serviços e eventos._

Depois de seis aulas lendo o mapa, chega a hora de usá-lo para decidir. Um Service Domain pintado de vermelho vale mais numa reunião de orçamento do que qualquer slide de "transformação". Nesta aula o BIAN vira ferramenta de trabalho: heatmap, fronteira de serviço, nome de evento e os erros que eu já vi se repetirem projeto após projeto.

## Cinco usos que pagam a leitura do mapa

O BIAN entra no meu dia a dia por cinco portas, e convém saber qual você está abrindo.

**Vocabulário comum:** quando produto, risco e engenharia chamam a mesma coisa de "conta", "contrato" e "posição", a reunião gasta metade do tempo traduzindo. Customer Agreement e Position Keeping encerram a discussão.

**Heatmap de sistemas:** o inventário de aplicações projetado sobre os Service Domains. É o uso que mais rende em comitê de investimento e o centro desta aula.

**Fronteiras de serviço:** o mapa sugere onde um serviço termina e outro começa. Sugere, não manda; volto a isso adiante.

**Desenho de APIs:** os padrões funcionais e os action terms da aula 03 dão nome e forma a recurso, operação e evento sem reinventar convenção a cada squad.

**Ferramentas de agentes:** cada Service Domain é um candidato natural a tool com escopo delimitado; a aula 09 trata disso.

Os cinco usos compartilham uma regra: o mapa descreve capacidades de negócio, não software. Quem esquece isso produz o primeiro erro clássico da lista que fecha a aula.

## Heatmap: pintar cada domínio e decidir com critério

O caso é fictício: uma emissora de cartões de porte médio que também operava adquirência e decidiu sair desse negócio. Pegue os Service Domains da área de cartões e, para cada um, registre três dados: quais sistemas o cobrem, quanta dor ele gera (incidentes, fila de mudanças, retrabalho) e quanto custa manter. A cor sai desses três dados, não da opinião do dono do sistema.

Pintado o mapa, a decisão por domínio segue um critério explícito, escrito no topo da planilha para ninguém discutir caso a caso:

- **Construir** quando o domínio é diferencial competitivo. Na emissora fictícia, Fraud Detection e Customer Offer: o modelo de risco e a oferta personalizada são o que o cliente percebe.
- **Comprar** quando é commodity de rede ou regulada. Card Clearing, Card Network Participant Facility e Payment Settlement: ninguém ganha cliente por liquidar melhor com a bandeira.
- **Manter** quando funciona bem e muda pouco. Card Authorization e Card Transaction Tracking rodam há anos com incidente raro; mexer ali é risco sem retorno.
- **Aposentar** quando o domínio saiu do negócio. Merchant Acquiring Facility e Card Terminal Administration deixam de existir na operação, e o plano de saída vira item de roadmap com dono e data.

O heatmap não entrega a decisão pronta, entrega a conversa certa: quatro verbos, um critério e um mapa que todo mundo lê.

## Heatmap fictício da operação de cartões: quatro decisões no mapa

Cada Service Domain do BIAN 14 leva a decisão na segunda linha. As setas seguem uma compra do portador até a cobrança; o tracejado marca apoio ou saída.

### 🔐 Autorização e posição

- Card Authorization manter: estável, muda pouco (security)
- Card Transaction Tracking manter: posição do cartão (data)

### 🛒 Compensação e faturamento

- Card Clearing comprar: commodity de rede (external)
- Card Network Participant Facility comprar: regra da bandeira (external)
- Payment Settlement comprar: novo no v14 (external)
- Card Billing comprar: fatura é commodity (compute)
- Card Collections manter: cobrança funciona (compute)

### 🤖 Risco e relacionamento

- Fraud Detection construir: diferencial (ai)
- Customer Offer construir: oferta personalizada (ai)

### 🗑 Adquirência (saindo do negócio)

- Merchant Acquiring Facility aposentar: plano de saída (storage)
- Card Terminal Administration aposentar: junto com a adquirência (storage)

### Fluxos

- holder -> auth: autorização em milissegundos
- fraud -> auth: score de risco
- auth -> ctt: evento de autorização
- ctt -> clearing: transações do dia
- clearing -> network: arquivo da bandeira
- clearing -> settle: valores a liquidar
- ctt -> billing: fatura mensal
- billing -> collections: atraso
- offer -> holder: limite e oferta
- acq -> clearing: desligar após a migração
- terminal -> acq: sai junto

> **Na prática:** Na prática, o heatmap que funciona cabe numa página e tem data. Eu pinto com o time de operação, não com o de arquitetura: quem atende o plantão sabe onde dói. E escrevo o critério de decisão antes de pintar, porque depois cada dono de sistema descobre um motivo para o seu domínio ser "diferencial competitivo".

### Heatmap do caso fictício de cartões

1. **A autorização de cartão é o diferencial do emissor fictício e o sistema atual não escala. Decisão para Card Authorization?**
- [x] Construir, _Diferencial competitivo com dor real justifica construir._
- [ ] Comprar, _Comprar faz sentido para commodity, não para o diferencial._
- [ ] Manter, _O sistema atual não escala._
- [ ] Aposentar, _A capacidade continua essencial._

2. **Customer Billing roda num pacote de mercado estável e barato. Decisão?**
- [x] Manter, _Funciona bem e não é diferencial: não mexa._
- [ ] Construir, _Construir commodity que funciona é custo sem retorno._
- [ ] Aposentar, _Faturar continua sendo necessário._
- [ ] Separar em 3 microsserviços, _Fronteira nova sem motivo de escala, falha ou auditoria._

3. **Qual é o erro do '340 microsserviços'?**
- [x] Tratar cada Service Domain como serviço obrigatório, _Troca um monólito por custo de rede, deploy e plantão._
- [ ] Usar menos serviços do que o BIAN recomenda, _O BIAN não recomenda número de serviços._
- [ ] Publicar eventos em vez de APIs, _Eventos e APIs convivem._
- [ ] Ignorar a ISO 20022, _É outro problema._

## Fronteiras candidatas e nomes de evento

Service Domain é fronteira candidata de serviço, não fronteira obrigatória. O BIAN desenha cada domínio para ser autônomo; isso o torna um bom ponto de corte, mas não quer dizer que cada corte deva virar um deploy separado.

Eu agrupo domínios por três eixos: **time** (quem opera junto implanta junto), **taxa de mudança** (o que muda toda semana não convive bem com o que muda uma vez por ano) e **risco** (o que derruba autorização não pode dividir processo com relatório gerencial). Na emissora fictícia, Card Authorization e Card Transaction Tracking podem viver no mesmo serviço: mesmo time, mesma cadência, mesmo plantão.

Separo quando um de três sinais aparece: **escala** diferente (autorização em milissegundos, faturamento em lote noturno), **falha** que precisa ser isolada (fraude fora do ar não pode travar a compra) ou **auditoria** que exige trilha própria (Customer Consent e tudo que a LGPD toca).

Para eventos, uma convenção só: Behavior Qualifier mais verbo no passado. `AmountBlockInitiated` diz qual qualificador mudou e qual action term aconteceu. Quem recebe o evento sabe onde ele nasceu no mapa sem abrir documentação. Aplique a mesma fórmula aos seus Behavior Qualifiers e evite verbos genéricos como `Updated` quando o action term existe.

## Quatro erros que eu vi se repetirem

**Tratar o mapa como planta:** o Service Landscape descreve capacidades, não componentes. Quem o lê como diagrama de implantação sai desenhando um sistema por caixa.

**Os "340 microsserviços":** o número é ilustrativo, a cena é real. Trocar um monólito por um serviço por Service Domain e descobrir que o custo mudou de lugar: latência de rede entre chamadas, uma pipeline de deploy por serviço e um plantão que não sabe mais onde começar a investigar. Agrupe primeiro, separe por sinal.

**Semantic API como contrato de produção:** a API semântica define recurso e operação, e para aí. Autenticação, idempotência de retry, formato de erro, paginação e versionamento são decisões suas. Publicar o YAML do BIAN como está é publicar um contrato pela metade.

**Mapear para domínio obsoleto:** Payment Execution, Payment Order e Payment Instruction não existem mais no BIAN 14. Mapeamento antigo precisa migrar para Payment Order Initiation, Payment Orchestration e os demais domínios novos, senão o heatmap nasce com fantasmas.

Fora do Brasil, o mesmo mapa ajuda a conversar: o T2 do Eurosistema usa ISO 20022 desde março de 2023; PSD3 e PSR foram propostos pela Comissão Europeia em 2023 e seguem em negociação; nos Estados Unidos o FDX é a referência de compartilhamento de dados. O domínio é o mesmo; o regulador e a mensagem mudam.

## Para levar

- Heatmap é cobertura, dor e custo por Service Domain, pintado com quem opera.
- Construir o diferencial, comprar a commodity, manter o que funciona, aposentar o que saiu do negócio. Critério antes da tinta.
- Service Domain é fronteira candidata: agrupe por time, cadência e risco; separe por escala, falha ou auditoria.
- Evento é Behavior Qualifier mais verbo no passado. Semantic API é ponto de partida, não contrato de produção.

### 08. IA Builder: mapeamento e contratos com grounding

_Mapeamento assistido por IA que não inventa domínio, e revisão de contratos contra a Semantic API oficial._

A IA é boa em um trabalho que todo arquiteto detesta: ler as definições de todos os Service Domains e lembrar qual faz o quê. E é péssima em outro: inventar um nome plausível quando não encontra o certo. Esta aula mostra como ficar com a primeira parte e eliminar a segunda, com recuperação sobre as definições oficiais da v14, escolha com citação, validador de lista fechada e um humano que decide. Acelerar sim, terceirizar o julgamento não.

## A regra: o modelo escolhe, nunca cria

Mapear um sistema no BIAN é um problema de classificação com catálogo fechado. A v14 tem um conjunto finito de Service Domains, cada um com papel, resumo e funções descritos em texto. O trabalho do mapeador é olhar uma capacidade do sistema ("calcula o limite rotativo do cartão") e apontar o domínio que a contém. Não há domínio novo a inventar: se o nome não está no catálogo, a resposta está errada.

Isso muda como se usa o modelo. Em vez de perguntar "qual Service Domain cuida de X?" e aceitar o que vier, o pipeline faz **RAG sobre as definições oficiais** da versão escolhida: cada domínio vira um documento (papel, resumo, funções, action terms), indexado por embedding. Para cada capacidade, recuperam-se os candidatos mais próximos, e só então o modelo entra, com uma instrução estreita: **escolha entre estes candidatos, cite o trecho da definição que justifica a escolha e, se nenhum serve, responda "nenhum"**.

A última defesa é mecânica: um **validador com lista fechada**, os nomes exatos da v14. Qualquer saída fora da lista é rejeitada antes de chegar ao humano. O ponto é não depender da obediência do modelo. Modelo bem instruído erra pouco; validador não erra. Em sistemas financeiros, é esse o padrão que vale a pena: a regra que importa mora fora do prompt, em código pequeno e testável.

## Pipeline de mapeamento com validador e fila humana

A IA só escolhe entre candidatos recuperados das definições oficiais; o validador rejeita qualquer nome fora da v14; o humano decide e cada decisão vira métrica.

### 📚 Grounding: definições oficiais v14

- Catálogo BIAN v14 papel, resumo, funções, YAML (storage)
- Ingestão e chunking um documento por Service Domain (data)
- Bedrock Knowledge Bases índice vetorial (ai)

### 🤖 IA: rascunho, nunca decisão

- Recuperar candidatos top-k por capacidade (ai)
- Escolher com citação trecho da definição ou 'nenhum' (ai)

### 🔐 Validação mecânica

- Validador de lista fechada nomes exatos da v14 (security)
- Script de contrato rascunho vs YAML oficial (security)

### 👤 Humano: julgamento

- Fila de revisão candidato + citação + divergências (messaging)
- Heatmap assinado fronteiras decididas (data)

### 📏 Medição

- Métricas aceito, corrigido, rejeitado (data)

### Fluxos

- catalog -> ingest: 1. ingerir
- ingest -> kb: embeddings
- inventory -> retrieve: capacidade
- kb -> retrieve: 2. candidatos
- retrieve -> choose: 3. escolher
- choose -> validator: 4. nome + citação
- validator -> choose: fora da lista: rejeita
- validator -> queue: nome válido
- contract -> queue: divergências de campo
- queue -> heatmap: 5. humano decide
- heatmap -> metrics: 6. medir

## O pipeline em seis passos

1. **Ingerir as definições da versão escolhida**: Um documento por Service Domain da v14: papel, resumo, funções, action terms. Versão fixada e registrada; misturar versões é a origem de metade dos erros.

2. **Recuperar candidatos**: Para cada capacidade do inventário, buscar os domínios mais próximos por similaridade. O modelo nunca vê o catálogo inteiro, só os candidatos.

3. **Escolher com citação**: O modelo escolhe um candidato e cita o trecho da definição que sustenta a escolha. Sem trecho, sem escolha. "Nenhum" é resposta aceita.

4. **Validar na lista fechada**: Comparação exata contra os nomes da v14. Nome inventado, obsoleto ou antigo é rejeitado e volta com o motivo.

5. **Revisar com humano**: O revisor vê candidato, citação e alternativas, e decide. Fronteira entre vizinhos e exigência regulatória ficam sempre aqui.

6. **Medir**: Taxa de aceite sem correção, taxa de rejeição do validador, domínios mais corrigidos. É o que diz se vale aumentar a confiança ou apertar o prompt.

## Os quatro modos de falha que o validador pega (e o que ele não pega)

Quatro erros aparecem em todo mapeamento assistido, e três deles passam em revisão visual porque parecem corretos.

**Nome inventado:** o modelo responde "Card Limit Management" porque soa como BIAN. Não existe na v14. Sem lista fechada, o nome entra no heatmap e vira caixa num diagrama que ninguém vai conferir.

**Versão velha:** "Payment Execution" aparece em muito material público sobre BIAN e, portanto, no treinamento de qualquer modelo. Na v14 ele é obsoleto, junto com Payment Order e Payment Instruction; o fluxo de pagamento hoje passa por Payment Order Initiation, Payment Orchestration, Payment Confirmation, Payment Settlement e Payment Rail. Um modelo sem grounding responde a versão que leu mais vezes, não a que você escolheu.

**Rename perdido:** "Credit Card Position Keeping" virou Card Transaction Tracking. O nome antigo é plausível, descreve bem a função e está errado. O mesmo vale para Payment Initiation (hoje Payment Order Initiation) e Payment Rail Operations (hoje Payment Rail).

**Vizinhos confundidos:** Fraud Evaluation dá um veredito pontual sobre uma transação; Fraud Diagnosis analisa um caso suspeito ao longo do tempo. Os dois existem, os dois passam no validador, e a escolha errada coloca a fronteira do serviço no lugar errado. Esse é o erro que só a citação da definição e o revisor humano pegam. É por isso que o pipeline exige o trecho citado, não só o nome: a citação é o que permite ao revisor discordar em um minuto, em vez de reabrir o catálogo.

> **Minha leitura:** Na prática, o ganho não está em o modelo acertar mais que o arquiteto; está em ele ler as definições inteiras toda vez, coisa que ninguém faz na terceira semana de mapeamento. Eu uso a IA para o rascunho e a justificativa de cada célula do heatmap, e reservo o julgamento para onde ele é insubstituível: fronteira entre vizinhos, o que fica fora do mapa e o que o regulador exige. Quem assina o heatmap sou eu, não o pipeline.

### O validador da v14

1. **O modelo sugeriu 'Payment Execution'. O validador da v14…**
- [x] rejeita: o domínio está obsoleto na v14, _Payment Settlement é o substituto anunciado._
- [ ] aceita: o nome é oficial, _Foi oficial em versões antigas._
- [ ] pede ao modelo que confirme, _Confirmação do próprio modelo não é fonte._
- [ ] cria um domínio próprio, _Criar nome fora do padrão é o que se quer evitar._

2. **O modelo sugeriu 'Credit Card Position Keeping'. O que fazer?**
- [x] Rejeitar: na v14 o domínio é Card Transaction Tracking, _Rename perdido é um modo de falha clássico._
- [ ] Aceitar, o nome parece oficial, _Parecer oficial não é estar na lista da v14._
- [ ] Aceitar e corrigir depois, _O erro se espalha para heatmap e contratos._
- [ ] Trocar de modelo, _Qualquer modelo erra sem grounding; o validador é a defesa._

3. **Quem decide manter, comprar, construir ou aposentar?**
- [x] O arquiteto, com o rascunho da IA como insumo, _A IA acelera o rascunho; a decisão tem dono humano._
- [ ] O modelo, com limiar de confiança, _Confiança decide o que vai para revisão, não a decisão de portfólio._
- [ ] O fornecedor do core, _Conflito de interesse._
- [ ] O BIAN, _O BIAN dá o vocabulário, não a decisão._

## Contratos: o rascunho contra o YAML oficial

O mesmo princípio vale para contratos. Quando um time rascunha a API de um serviço mapeado em Payment Order Initiation, a referência é o YAML oficial da Semantic API v14 desse domínio, não a memória do modelo. Um script simples carrega o contrato rascunhado e o oficial, alinha as operações pelo action term e compara os campos: no Payment Order Initiation, `PayerReference`, `PayeeReference`, `Amount` e `Currency` precisam estar lá, com o mesmo nome e no mesmo lugar. Campo renomeado, campo faltando, tipo diferente: o script aponta a divergência linha a linha, e o revisor decide se foi desvio proposital ou descuido.

Desvio proposital existe e é legítimo. A Semantic API define semântica, não a sua implementação: ela não diz qual é a chave de idempotência do seu endpoint. No Pix, quem define isso é o catálogo de serviços do SPI, por mensagem; a Semantic API não entra nesse detalhe. Então **idempotência é decisão sua**, registrada como extensão documentada do contrato, não como campo "que o BIAN pediu". O script deve conhecer essas extensões declaradas para não marcar como erro o que foi decidido.

Sobre a infraestrutura: a opção gerenciada de RAG na AWS é o Amazon Bedrock Knowledge Bases, que cuida de ingestão, chunking, embedding e recuperação. Use quando a equipe não quer operar índice vetorial próprio e as definições cabem em um fluxo de ingestão simples. O validador de lista fechada e o script de contratos continuam sendo código seu, pequeno e testável. É a parte que menos muda quando você troca de modelo, e a que mais protege o mapa.

## O que levar desta aula

- O modelo escolhe entre candidatos recuperados das definições oficiais da v14 e cita o trecho; ele nunca cria nome de domínio.
- O validador de lista fechada é código, não prompt: nome inventado, obsoleto (Payment Execution) ou antigo (Credit Card Position Keeping) não passa.
- Vizinhos como Fraud Evaluation e Fraud Diagnosis passam no validador; só a citação e o revisor humano resolvem.
- Contrato rascunhado se compara com o YAML oficial por script; idempotência é decisão sua, documentada como extensão.
- Meça aceite, correção e rejeição por domínio: é o que justifica confiar mais ou apertar o pipeline.

## Perguntas frequentes

### E se nenhum candidato recuperado serve para a capacidade?

"Nenhum" é uma resposta válida e deve ir para a fila humana com os candidatos descartados. Em geral significa uma de três coisas: a capacidade está descrita em termos de tecnologia e não de negócio, ela pertence a dois domínios e precisa ser dividida, ou está fora do escopo do BIAN. Forçar um encaixe é pior que deixar a célula em aberto.

### Posso deixar a IA preencher o heatmap inteiro e revisar só por amostragem?

Só para o rascunho. A amostragem serve para medir a qualidade do pipeline, não para substituir a decisão sobre fronteiras: o custo de uma fronteira errada é de anos de integração no lugar errado, não de uma célula pintada. Use a métrica de aceite para decidir onde a revisão pode ser mais leve, domínio por domínio.

### 09. Agentes com fronteira de domínio e avaliação

_Ferramentas do agente como Service Operations, com política, aprovação humana e avaliação contínua._

Nas oito aulas anteriores o BIAN serviu para ler o banco. Nesta última ele serve para dar limite a um agente de IA: cada ferramenta que o agente pode chamar é uma Service Operation de um Service Domain, com política antes, humano no meio quando há dinheiro e medição depois. Sem essa fronteira, o agente é só um script com acesso ao core bancário.

## Uma ferramenta por Service Operation

A regra que organiza tudo: **uma ferramenta, uma Service Operation**. O agente não recebe uma ferramenta chamada `banco` com dez parâmetros. Ele recebe `Retrieve` no Current Account para consultar saldo e `Initiate` no Payment Order Initiation para criar uma ordem de pagamento. O nome da ferramenta já diz qual domínio ela toca e qual action term ela executa, exatamente o vocabulário da aula 03.

Isso resolve três problemas de uma vez.

**Fronteira:** o agente só alcança os domínios que você expôs. Se não existe ferramenta em Customer Consent, ele não altera consentimento, por mais criativo que seja o prompt.

**Auditoria:** cada chamada de ferramenta vira uma linha de log com Service Domain, action term e Control Record afetado. Quem audita lê o mesmo mapa que o arquiteto desenhou.

**Contrato:** a ferramenta nasce do OpenAPI da Semantic API (aula 04). O schema que valida a requisição do canal valida também a requisição do agente. Não existe um segundo contrato, mais frouxo, só para a IA.

Na prática, a tentação é agrupar: 'uma ferramenta de pagamentos' que decide sozinha se consulta, inicia ou confirma. Resista. Ferramenta larga é fronteira larga, e fronteira larga é o que você passou o módulo 2 aprendendo a não desenhar. Lembre também que Payment Execution e Payment Instruction são obsoletos na versão 14: ferramenta com esses nomes é dívida de nascença.

## O laço do agente bancário

Caminho de um pedido do cliente até a Service Operation, com política, aprovação humana e auditoria no meio.

### 🤖 Agente: raciocínio e plano

- Agente escolhe a ferramenta e preenche os campos (ai)

### 🟧 AWS: Bedrock AgentCore

- AgentCore Gateway OpenAPI exposto como ferramentas MCP (network)
- Policy (Cedar) avalia a regra antes de cada chamada (security)

### 🔐 Controle humano

- Fila de aprovação toda movimentação de dinheiro (user)
- Revisão LGPD art. 20 decisão sobre a pessoa (user)

### 🏦 Banco: Service Domains BIAN 14

- Current Account Retrieve: saldo (data)
- Payment Order Initiation Initiate: ordem de pagamento (compute)
- Payment Confirmation confirma ao cliente (messaging)

### 📤 Auditoria e avaliação

- Trilha de auditoria domínio, action term, Control Record (storage)
- Golden set e métricas precisão, recall, regressão (ci)

### Fluxos

- client -> agent: pedido em linguagem natural
- agent -> gateway: chama a ferramenta
- gateway -> policy: regra Cedar antes da chamada
- policy -> ca: Retrieve permitido
- policy -> approval: Initiate exige humano
- approval -> poi: aprovado
- poi -> pc: ordem aceita
- pc -> client: resposta ao cliente
- approval -> review: negativa: direito de revisão
- gateway -> audit: registra cada chamada
- audit -> eval: alimenta a avaliação

## Gateway, política e aprovação humana

O desenho acima tem três camadas entre o agente e o banco, e nenhuma é opcional.

**Gateway:** o Amazon Bedrock AgentCore Gateway recebe a especificação OpenAPI da Semantic API e a expõe como ferramentas MCP. O agente enxerga `Retrieve` e `Initiate` como ferramentas; o banco continua enxergando a mesma API de sempre. Nenhum código de integração novo, nenhum contrato paralelo.

**Política:** o Policy in AgentCore avalia regras Cedar antes de cada chamada de ferramenta. A regra é declarativa: este agente, para este cliente, pode chamar `Retrieve` no Current Account; pode chamar `Initiate` no Payment Order Initiation só se houver aprovação registrada. A política vive fora do prompt. Prompt é sugestão; política é bloqueio.

**Aprovação humana:** toda movimentação de dinheiro passa por uma pessoa. Não é desconfiança do modelo, é desenho: o agente prepara a ordem com todos os campos preenchidos, o humano aprova em uma fila, e só então o `Initiate` acontece. Consulta de saldo não precisa disso; transferência precisa, sempre.

Há uma quarta camada que o diagrama marca e muita gente esquece: o **art. 20 da LGPD** dá ao titular o direito de pedir revisão de decisões tomadas unicamente com base em tratamento automatizado que afetem seus interesses. Se o agente nega um limite ou recusa uma operação, a pessoa pode pedir que um humano reveja. Então o laço precisa de um caminho de volta, com a decisão, o motivo e quem revisou.

### O laço do agente bancário

Ordene do pedido do cliente à auditoria.

1. Cliente pede para pagar uma conta
2. Agente consulta o saldo com Retrieve no Current Account
3. Política no gateway avalia a chamada
4. Cliente aprova o pagamento
5. Agente executa Initiate no Payment Order Initiation
6. Chamada e decisão ficam na auditoria

> **Na prática:** Na prática, o que separa um agente bancário de uma demo é a ordem das camadas. Já vi protótipo colocar a aprovação humana no prompt ('peça confirmação antes de pagar') e chamar isso de controle. Prompt não é controle. Controle é a regra Cedar que devolve negado quando não há aprovação registrada, e o log que prova isso seis meses depois. Monte a demo com a fronteira pronta: é mais lento no primeiro dia e muito mais barato em todos os outros.

## Avaliação: o agente também tem golden set

Na aula 08 a IA rascunhou mapeamentos e um humano decidiu. A pergunta que fecha o curso é outra: como você sabe que ela continua acertando?

**Golden set:** um conjunto de casos com a resposta certa, revisado por dois arquitetos, com a versão do BIAN fixada no próprio arquivo (14.0, e não 'a atual'). Dois revisores porque mapeamento é interpretação: onde os dois discordam, o caso vira discussão e, resolvido, vira o exemplo mais valioso do conjunto. Versão fixada porque um rename como Payment Rail Operations para Payment Rail muda a resposta certa sem mudar o sistema.

**Precisão e recall por domínio:** a média geral esconde o problema. Um agente pode acertar tudo em Current Account e errar sistematicamente em Payment Orchestration, que é novo na versão 14. Meça por Service Domain e olhe para os piores, não para a média.

**Limiar de confiança:** abaixo de um valor que você define, o caso não é decidido pelo agente; vai para a fila humana. O valor certo depende do seu conjunto e do custo de errar em cada domínio. O que não pode é não existir.

**Regressão:** a cada troca de modelo e a cada versão nova do BIAN, rode o golden set inteiro antes de promover. Modelo novo não é melhor por definição; é diferente, e diferente precisa de prova.

## Rotina de avaliação do agente

1. **Congele a versão**: BIAN 14.0 escrito no arquivo do golden set e no grounding do agente. Nome obsoleto na resposta conta como erro.

2. **Revise em dupla**: Dois arquitetos aprovam cada caso. Divergência fica registrada com a decisão final e o motivo.

3. **Meça por domínio**: Precisão e recall por Service Domain. Ordene do pior para o melhor e ataque o topo da lista.

4. **Rode a regressão antes de promover**: Troca de modelo ou de versão do BIAN só sobe depois do golden set inteiro. Queda em qualquer domínio bloqueia.

### Recapitulação do curso

- **Módulo 1**: O mapa: camadas, Control Record, padrões funcionais e action terms.
- **Módulo 2**: Do domínio à regulação: Semantic API, Pix e Open Finance no mapa.
- **Módulo 3**: No trabalho: heatmap, fronteiras, IA com grounding e agentes avaliados.

## Os três primeiros módulos em uma página

Antes da parte 2 do curso, o caminho que você percorreu até aqui.

**Módulo 1, o mapa:** o BIAN é um mapa de capacidades, não um sistema (aula 01). As camadas organizam Service Domains, cada um com um Control Record que diz o que ele administra (aula 02). Padrões funcionais e action terms dão o verbo: Retrieve, Initiate, Update, Execute (aula 03). E o caminho segue do Service Domain até o OpenAPI da Semantic API (aula 04).

**Módulo 2, o Brasil no mapa:** Pix distribuído entre Payment Order Initiation, Payment Rail, Payment Settlement e Payment Confirmation, com os domínios novos da versão 14 no lugar dos obsoletos (aula 05). Open Finance, SCR, LGPD e Banco Central como obrigações que atravessam domínios, com Customer Consent como domínio próprio (aula 06).

**Módulo 3, o trabalho:** heatmap para ver onde os sistemas se sobrepõem e as fronteiras erradas que todo mundo desenha uma vez (aula 07). IA com grounding nas definições oficiais para rascunhar mapeamentos e contratos, humano decidindo e tudo medido (aula 08). E esta aula: agente com ferramentas por Service Operation, política, aprovação humana e avaliação contínua.

O exame final está na página do curso e cobre o curso inteiro, das partes 1 a 3; aprovado, libera o certificado. Antes dele, vêm a parte 2 (um banco por dentro) e a parte 3 (o crédito por dentro).

## Módulo 4: Um banco por dentro

A anatomia do banco e as três perguntas, cadastro e abertura de conta, salário, boleto e débitos, cartão, crédito e cobrança, investimentos, fraude e lavagem de dinheiro.

### 10. A anatomia do banco e as três perguntas

_Um banco em seis grupos que cabem numa página, e as três perguntas que se faz a cada parte._

A parte 2 começa depois do documentário de cerca de 65 minutos em que Marina, cliente fictícia, atravessa um ano de vida dentro do banco. A pergunta agora não é “quantos sistemas existem?”, é “quem é dono de cada registro, como esse registro vive, e que fato ele publica para os vizinhos?”.

## O banco em uma página

Eu uso seis grupos didáticos para explicar o banco porque o mapa oficial do BIAN 14.0 é rico demais para ser a primeira tela de uma conversa. Esses grupos não existem no BIAN. São uma leitura minha para ensinar, revisar arquitetura e orientar a segunda parte do curso.

A analogia é simples: pense no banco como uma cidade. Os canais são a portaria: app, agência, central de atendimento. Cliente é o cartório, onde a identidade, o relacionamento e as primeiras checagens ganham registro. Produtos são as lojas: conta, cartão, crédito, investimento. Pagamentos são as estradas, onde o dinheiro se move. Risco e compliance são a fiscalização, testando fraude, prevenção à lavagem de dinheiro e aderência. Finanças, com contabilidade e tesouraria, é a prefeitura que fecha as contas.

Essa divisão ajuda a ler a jornada da Marina sem virar uma lista de sistemas. Quando ela abre relacionamento, compra, recebe, paga, atrasa, investe ou aparece em uma análise de risco, cada movimento passa por donos diferentes de registro. O valor do BIAN aparece quando você para de perguntar “qual sistema faz isso?” e começa a perguntar “qual Service Domain controla esse fato?”.

## Seis grupos didáticos para ler o banco
| Grupo | Analogia | Domínio v14 de exemplo | Leitura operacional |
| --- | --- | --- | --- |
| Canais | Portaria: app, agência e central | Session Dialogue | Conduz a conversa antes de qualquer produto aparecer. |
| Cliente | Cartório | Party Lifecycle Management | Acompanha o relacionamento desde as primeiras checagens. |
| Produtos | Lojas | Current Account | Representa a conta como produto operacional do cliente. |
| Pagamentos | Estradas | Payment Orchestration | Coordena cada movimento. É novo na v14. |
| Risco e compliance | Fiscalização | Fraud Evaluation | Testa transações antes que o prejuízo vire rotina. |
| Finanças | Prefeitura que fecha as contas | Financial Accounting | Transforma fatos em lançamentos contábeis. |

> **Minha leitura:** Na prática, eu não uso esses seis grupos para substituir o BIAN. Uso para chegar vivo à conversa de arquitetura. Em documento formal, cite a visão oficial da v14, matriz com 5 Business Areas e 38 Business Domains, ou cadeia de valor com 8 Business Areas, e diga qual visão está usando.

## Seis grupos em volta das três perguntas

Agrupamento didático do autor. As visões oficiais do BIAN 14.0 continuam sendo a matriz e a cadeia de valor.

### 👤 Cliente: jornada da Marina

- Marina cliente fictícia (user)

### 🔎 Perguntas: método de leitura

- Dono do registro Control Record (data)
- Padrão funcional vida do registro (compute)
- Fato publicado vizinhos do domínio (messaging)

### 🏦 Cidade: grupos didáticos

- Canais Session Dialogue (edge)
- Cliente Party Lifecycle Management (data)
- Produtos Current Account (compute)
- Pagamentos Payment Orchestration (messaging)
- Risco e compliance Fraud Evaluation (security)
- Finanças Financial Accounting (data)

### Fluxos

- marina -> channels: entra pelo canal
- channels -> customer: identifica relacionamento
- customer -> products: habilita produto
- products -> payments: gera movimento
- payments -> risk: pede avaliação
- payments -> finance: gera fato contábil
- owner -> pattern: explica ciclo de vida
- pattern -> event: define fato publicável
- event -> payments: amarra vizinhos

## As três perguntas que evitam arquitetura decorativa

Para cada parte do banco, faça três perguntas na mesma ordem. Primeira: quem é o dono do registro? Em linguagem BIAN, qual Service Domain controla o Control Record. Segunda: qual é o padrão funcional? Esse padrão diz como o registro nasce, vive e termina. Terceira: que fato esse dono publica para os vizinhos?

Se uma dessas perguntas fica sem resposta, o problema apareceu antes do código. Não adianta discutir Kafka, REST, filas, microsserviços ou orquestração se ninguém sabe qual domínio tem autoridade sobre o registro. Sem dono, todo sistema vira fonte da verdade quando convém, e nenhuma auditoria aceita isso por muito tempo.

A contagem que fiz no repositório HTML público da v14 encontrou 346 nomes únicos de Service Domain. Desses, 7 aparecem marcados como obsoletos, todos ligados a pagamentos. Payment Execution, Payment Order e Payment Instruction entram aqui só como obsoletos. Também aparecem 19 sem status de registro, que são os novos da v14, como Payee Management, Customer Consent e Payment Settlement. O restante aparece registrado.

Esse número não serve para impressionar. Serve para lembrar que arquitetura bancária é mapa de responsabilidade. Você não precisa decorar 346 nomes para trabalhar bem, mas precisa saber qual nome usar quando um registro vira disputa.

### Domínio e padrão funcional, conferidos nos YAMLs v14

- **Corporate Payroll Services** → Fulfill
- **Customer Billing** → Process
- **Customer Event History** → Track
- **Party Routing Profile** → Monitor
- **Corporate Treasury** → Manage
- **Asset And Liability Management** → Direct
- **Fraud Model** → Design
- **Disbursement** → Transact
- **Collateral Allocation Management** → Allocate
- **Regulatory Reporting** → Administer

## O que cada pergunta força

- **Dono do registro:** separa sistema que mostra dado de domínio que tem autoridade sobre o Control Record.
- **Padrão funcional:** mostra se o domínio cumpre obrigação, executa procedimento, acompanha log, monitora estado ou faz outro tipo de trabalho.
- **Fato publicado:** transforma integração em contrato entre vizinhos, não em vazamento casual de tabela.
- **Pergunta sem resposta:** indica fronteira errada, Control Record ambíguo ou evento inventado antes da modelagem.

## Como conferir o padrão funcional sem adivinhar

O jeito mais limpo de conferir o padrão funcional é abrir o YAML oficial da v14 no repositório `bian-official/public`, pasta `release14.0.0`, e ler a descrição do Control Record. Ela normalmente começa com uma frase padrão.

Quando a descrição começa com `Fulfill any scheduled and ad-hoc obligations...`, o padrão é Fulfill. Quando começa com `Complete work tasks following a defined procedure`, é Process. `Maintain a log of transactions` aponta para Track. `Monitor and define the status/rating` aponta para Monitor. `Oversee the working of a business unit` aponta para Manage. `Define the policies, goals & objectives` aponta para Direct. `Create and maintain a design` aponta para Design. `Execute a well-bounded financial transaction` aponta para Transact. `Maintain an inventory or holding...` aponta para Allocate. `Handle and assign the day to day activities...` aponta para Administer.

Quando a descrição está vazia, eu não finjo certeza. O nome do Control Record dá pista: um nome terminando em `Procedure` sugere Process, um nome terminando em `Assessment` sugere Assess. Mas isso é inferência minha, não leitura direta do BIAN. Essa distinção parece pequena até alguém usar a ficha em uma decisão de arquitetura, contrato de API ou revisão regulatória.

## Método das próximas aulas

1. **Comece pela cena da Marina**: A personagem é fictícia. A cena dá contexto operacional antes de qualquer nome de Service Domain.

2. **Passe pelo fluxo de domínios**: O fluxo será adaptado de um cenário oficial da v14. A ordem dos passos é minha leitura, porque o repositório lista linhas de vida, não setas de arquitetura.

3. **Confira a ficha**: Cada ficha traz domínio, Control Record e padrão funcional quando o YAML permite conferência direta.

4. **Aterre no Brasil**: A camada brasileira entra com norma e número oficial quando estiver no escopo: Pix, SPI, DICT, Open Finance, SCR, LGPD e resoluções CMN.

5. **Feche com segunda de manhã**: A aula termina com o que você faria em uma revisão real: fronteira, dono de registro, contrato e evidência.

## Onde a IA entra sem tomar a decisão

A forma IA Builder de trabalhar combina bem com BIAN porque o mapa é grande, textual e cheio de nomes parecidos. A IA pode rascunhar o mapeamento de uma jornada, sugerir Service Domains candidatos, comparar descrições de Control Record e propor contratos de evento. Mas ela precisa trabalhar com grounding nas definições oficiais. Sem isso, ela vira um gerador de nomes plausíveis.

O humano decide porque a decisão não é só semântica. É operacional, regulatória e política no bom sentido da palavra: quem responde pelo dado, quem corrige incidente, quem assina evidência, quem sofre quando a fronteira está errada. Uma sugestão de IA pode dizer que um fato parece pagamento, cliente ou risco. Só a revisão de arquitetura decide se aquele fato pertence a Payment Orchestration, Customer Consent, Fraud Evaluation ou outro domínio dentro do contexto real.

Medição fecha o ciclo. Conte acertos de mapeamento, divergências por domínio, contratos rejeitados e casos em que faltou grounding. O objetivo não é deixar a IA “autônoma”. É reduzir trabalho repetitivo sem perder precisão em um mapa onde nomes, padrões e registros carregam responsabilidade.

## Dúvidas que aparecem cedo

### Esses seis grupos são uma visão oficial do BIAN?

Não. São uma divisão didática minha. As visões oficiais da v14 são a matriz, com 5 Business Areas e 38 Business Domains, e a cadeia de valor, com 8 Business Areas.

### Posso usar esses grupos em documento de arquitetura?

Pode, desde que diga que são didáticos e cite a visão oficial usada como base. O problema não é simplificar, é esconder que você simplificou.

### A ordem das jornadas das próximas aulas é oficial?

Não como sequência de setas. Ela será adaptada de cenário oficial da v14, mas a ordem dos passos é minha leitura. O repositório lista linhas de vida dos cenários.

### Checagem rápida

1. **Os seis grupos (canais, cliente, produtos, pagamentos, risco e compliance, finanças) são:**
- [x] Um agrupamento didático do curso, que não existe no BIAN, _As visões oficiais da v14 são a matriz e a cadeia de valor._
- [ ] A visão oficial em matriz da v14, _A matriz tem 5 Business Areas e 38 Business Domains._
- [ ] A visão oficial de cadeia de valor da v14, _A cadeia de valor tem 8 Business Areas._
- [ ] Os seis Business Domains de um banco de varejo, _Não há lista oficial de seis domínios._

2. **Onde se confere o padrão funcional de um Service Domain com Semantic API?**
- [x] Na descrição do control record no YAML oficial da v14, _A descrição começa com a frase-padrão do padrão._
- [ ] No nome do Business Domain, _O Business Domain agrupa domínios com padrões diferentes._
- [ ] Perguntando a um modelo de linguagem, _Resposta de modelo não é fonte._
- [ ] No número de operações da API, _O número de operações não diz o padrão._

3. **Quais são as três perguntas que o curso faz a cada parte do banco?**
- [x] Quem é o dono do registro, qual é o padrão funcional e que fato ele publica, _Uma pergunta sem resposta mostra o problema antes do código._
- [ ] Qual sistema, qual fornecedor e qual custo, _São perguntas de inventário, não de mapa._
- [ ] Qual tabela, qual índice e qual réplica, _O Control Record é conceito de negócio._
- [ ] Quantos microsserviços, quantos times e quantos deploys, _Service Domain é fronteira candidata, não contagem de serviços._

## Veredito

Use os seis grupos para explicar o banco, mas use as três perguntas para desenhar arquitetura. O agrupamento ajuda a conversa. O Control Record, o padrão funcional e o fato publicado é que seguram a decisão quando o desenho sai da aula e entra em revisão técnica.

### 11. Cliente: cadastro, conheça seu cliente e abertura de conta

_O registro mais reutilizado do banco, o que a norma pede e um nome obsoleto escondido no cenário oficial._

A Marina, personagem fictícia, baixa o app do banco, fotografa o documento e tira uma selfie. Para ela, isso parece cadastro. Para a arquitetura, nasce o registro mais reutilizado do banco: quem é essa pessoa, quais dados sustentam essa identidade e quais contratos podem ser criados a partir dela.

## O cadastro não é tela, é fonte de verdade

A pergunta perigosa aqui não é "qual tela captura o documento?", é "quem tem autoridade para dizer quem é a Marina depois que a tela fecha?". Em banco, cadastro vira dependência de quase tudo: conta, contrato, cartão, crédito, cobrança, atendimento, prevenção à lavagem de dinheiro e auditoria.

No cenário oficial v14 **Execute Customer Onboarding API version** (view 55753), aparecem linhas de vida como Session Dialogue, Correspondence, Customer Agreement, Party Reference Data Directory, Location Data Management, Party Lifecycle Management, Regulatory Compliance, Issued Device Administration e Document Directory. A ordem que uso para ensinar essa jornada é leitura minha: Session Dialogue conduz as telas; Party Reference Data Directory registra dados e contatos; Document Directory guarda documentos; Location Data Management confere o endereço; Regulatory Compliance avalia as checagens regulatórias; Party Lifecycle Management ativa o relacionamento; Customer Agreement formaliza o contrato mestre; Issued Device Administration emite as credenciais.

Essa distinção parece acadêmica até o primeiro incidente. Se todo sistema escreve um pedaço do cadastro, ninguém sabe qual CPF, endereço, telefone ou consentimento vale quando há divergência. Um único dono para o registro da pessoa não é preciosismo de modelagem, é a diferença entre operar uma instituição auditável e manter uma colcha de retalhos com tela bonita.

> **Minha leitura de arquiteto:** Na prática, eu separo cadastro, documento, checagem regulatória, contrato mestre e contrato de produto porque cada um envelhece em ritmo diferente. Misturar tudo no sistema de conta parece rápido no primeiro sprint, mas cobra juros em toda auditoria, reabertura de cadastro e produto novo.

## Conheça seu cliente tem estado, vencimento e evento

Na v14, eu procurei e não encontrei um Service Domain chamado KYC ou conheça seu cliente. Isso importa. Quando a arquitetura inventa um domínio genérico chamado KYC, ela costuma esconder três coisas diferentes: dados da parte, evidências documentais e avaliação regulatória.

O BIAN traz cenários oficiais mais específicos. **Perform Customer Due Diligence Assessment** (view 55550) envolve Regulatory Compliance, Guideline Compliance, Party Lifecycle Management, Legal Entity Directory e Party Reference Data Directory. **Perform Regulatory KYC Analysis** (view 55240) envolve Party Lifecycle Management, Customer Credit Rating, Legal Entity Directory, Correspondence, Regulatory Compliance, Customer Behavior Insights e Information Provider Operation.

No Brasil, a Circular BCB 3.978/2020, art. 13, fala em procedimentos destinados a conhecer o cliente, com identificação, qualificação e classificação. O § 1º, I, exige medidas reforçadas para categorias de maior risco, conforme a avaliação interna de risco. Isso não combina com checkbox único no primeiro dia.

A ficha do Party Lifecycle Management diz que ele acompanha o estado do relacionamento da parte com o banco desde as checagens iniciais e lista reavaliações periódicas. Seus Behavior Qualifiers no YAML são Qualification, Documentation, Precedents e IdentityProofing. Eu não cito o padrão funcional dele: a descrição do control record está vazia no YAML, e o nome do control record só sugere um padrão, sem confirmar.

## Da Marina à conta corrente

A jornada separa identidade, evidência, avaliação, contrato mestre, contrato de produto e conta. A linha Payment Order aparece como armadilha do cenário publicado e deve ser validada contra a v14.

### 👤 Entrada: diálogo

- Session Dialogue telas e sessão (frontend)

### 📚 Identidade: registros

- Party Reference Data Directory dados e contatos (data)
- Document Directory documento e selfie (storage)
- Location Data Management endereço (data)

### 🔐 Checagem: risco e ciclo de vida

- Regulatory Compliance avaliação regulatória (security)
- Party Lifecycle Management estado do relacionamento (compute)

### 🧾 Contratos: mestre e produto

- Customer Agreement contrato mestre (data)
- Customer Product And Service Eligibility elegibilidade (compute)
- Sales Product Agreement contrato da conta (data)

### 🏦 Conta: operação

- Product Directory condições da conta (data)
- Current Account conta aberta (data)
- Issued Device Administration credenciais e débito (security)
- Financial Accounting registro contábil (data)

### ⚠️ Validação: nome obsoleto

- Payment Order obsoleto na v14 (messaging)
- Payment Confirmation substituto anunciado (messaging)

### Fluxos

- marina -> session: inicia onboarding
- session -> party: registra dados
- session -> docs: envia evidências
- party -> location: confere endereço
- docs -> reg: suporta checagem
- reg -> life: muda estado
- life -> master: ativa relacionamento
- product -> elig: traz condições
- elig -> sales: permite contratar
- sales -> account: abre conta
- account -> device: emite acesso
- account -> acct: registra
- oldpay -> payconf: trocar após validação v14

## Abrir conta é outra jornada

Depois que a Marina existe como parte conhecida, vem a pergunta de produto: ela pode abrir qual conta, sob quais condições e com qual contrato? O cenário oficial **Handle Request to Open Retail Current Account** (view 54760) ajuda, mas precisa ser lido com validador na mão.

A ordem que uso é esta: Product Directory traz as condições; Customer Product And Service Eligibility diz para quais contas ela é elegível; Party Lifecycle Management verifica; Sales Product Agreement cria o contrato do produto; Current Account abre a conta; Issued Device Administration emite o cartão de débito; Financial Accounting registra.

Customer Agreement é o contrato mestre. Sales Product Agreement é o contrato de cada produto. Separar os dois evita reescrever o contrato mestre cada vez que a Marina contrata uma conta, um cartão ou outro produto. Essa separação também deixa claro onde fica a obrigação geral de relacionamento e onde fica a condição específica daquele produto.

A armadilha é que o próprio cenário publicado na v14 ainda lista a linha de vida Payment Order, com a mensagem **Create Payment Order for Fees and Charges**. Payment Order está obsoleto na v14, e Payment Confirmation aparece como substituto anunciado nas release notes. Copiar cenário sem conferir nome por nome traz nome velho para o desenho novo.

## Onde cada responsabilidade deve morar
| Responsabilidade | Domínio adequado | Erro comum | Por que separo |
| --- | --- | --- | --- |
| Dados e contatos da pessoa | Party Reference Data Directory, padrão Catalog | Cada sistema escreve um pedaço | Um dono reduz divergência em auditoria e atendimento |
| Endereço | Location Data Management, padrão Catalog | Endereço preso no sistema de conta | Endereço serve mais de uma relação e muda no tempo |
| Checagem regulatória | Regulatory Compliance, padrão Assess | KYC tratado como checkbox único | Risco tem classificação, reforço e reavaliação |
| Contrato mestre | Customer Agreement, padrão Agree Terms | Misturar contrato geral com contrato de produto | O relacionamento não deve ser refeito a cada produto |
| Contrato de produto | Sales Product Agreement, padrão Agree Terms | Abrir conta sem contrato específico | Cada produto tem condição própria |
| Credencial e dispositivo | Issued Device Administration, padrão Allocate | Cartão e credencial viram detalhe da conta | Credencial tem ciclo de vida próprio |

### Cadastro e abertura de conta

1. **Qual domínio guarda o contrato mestre do cliente?**
- [x] Customer Agreement, _É Agree Terms; cada produto se pendura nele._
- [ ] Sales Product Agreement, _Guarda o contrato de cada produto, não o mestre._
- [ ] Party Reference Data Directory, _Guarda quem é a pessoa, os contatos e os vínculos._
- [ ] Document Directory, _Guarda os documentos._

2. **Conheça seu cliente é um Service Domain do BIAN v14?**
- [x] Não; é composição de domínios em cenários oficiais, _Due diligence e análise regulatória combinam Party Lifecycle Management, Regulatory Compliance e outros._
- [ ] Sim, chamado KYC Management, _Esse nome não existe na v14._
- [ ] Sim, é o Regulatory Compliance, _Regulatory Compliance é uma das peças, não o processo inteiro._
- [ ] Sim, novo na v14, _Os novos da v14 incluem Customer Consent e Payee Management, não KYC._

3. **Segundo a ficha, o Party Lifecycle Management termina na abertura da conta?**
- [x] Não; ele mantém um calendário e faz reavaliações periódicas, _O relacionamento tem estado e vencimento._
- [ ] Sim, ele só existe no onboarding, _A ficha fala em reavaliações periódicas._
- [ ] Sim, depois o Current Account assume, _A conta não cuida do relacionamento com a pessoa._
- [ ] Ele não participa da abertura de conta, _Ele verifica a cliente no cenário oficial de abertura._

4. **Que nome do cenário oficial de abertura de conta precisa ser trocado antes de desenhar?**
- [x] Payment Order, obsoleto; substituto anunciado: Payment Confirmation, _O cenário da v14 ainda usa um nome obsoleto na mesma versão._
- [ ] Current Account, _Está registrado na v14._
- [ ] Sales Product Agreement, _Está registrado na v14._
- [ ] Customer Product And Service Eligibility, _Está registrado na v14._

## Segunda de manhã

- **Um dono para a pessoa:** escolha quem manda no registro da Marina e faça o resto ler dele.
- **KYC com estado:** trate identificação, qualificação, classificação, medidas reforçadas e reavaliação como ciclo de vida, não como flag.
- **Documento fora da conta:** documento e selfie têm evidência, retenção e reprocessamento próprios.
- **Contrato mestre separado:** Customer Agreement não deve ser reescrito a cada Sales Product Agreement.
- **Validador v14 sempre:** cenário oficial também pode carregar nome obsoleto, como Payment Order.

## Perguntas que sempre aparecem

### Posso criar um domínio interno chamado KYC?

Pode, se você souber que está criando uma convenção interna, não copiando um Service Domain v14. Eu prefiro mapear para Party Lifecycle Management, Regulatory Compliance, Party Reference Data Directory e Document Directory, conforme a responsabilidade concreta.

### Por que não colocar tudo no sistema de conta?

Porque conta é produto. Pessoa, documento, endereço, estado regulatório e contrato mestre são usados antes, durante e depois da conta. Acoplar tudo à conta parece simples, mas torna reuso e auditoria mais caros.

### O que faço com Payment Order no cenário de abertura de conta?

Marque como nome obsoleto na v14 e valide a troca por Payment Confirmation no seu desenho. A lição não é decorar o substituto, é nunca importar cenário sem conferir cada Service Domain contra a versão certa.

### 12. Pagamentos de varejo: salário, boleto e débitos

_O dinheiro que entra e sai da conta, o que muda entre trilhos e os nomes parecidos com status diferentes._

Pagamento de varejo parece simples quando você olha só para o extrato. Entra salário, sai boleto, cai débito automático. A arquitetura começa quando você pergunta o que muda entre ordem, confirmação, liquidação, trilho e conta, porque nomes parecidos no mapa do BIAN têm responsabilidades bem diferentes.

## Salário não é um crédito, é um lote com promessa operacional

No cenário oficial v14 `Process Salary Payments for Internal Accounts`, view `54620`, o repositório ainda mostra linhas de vida com nomes antigos: `Payment Execution` e `Payment Order`. As release notes do BIAN 14.0 anunciam as trocas: `Payment Order` passa para `Payment Confirmation`; `Payment Execution` passa para `Payment Settlement`. A ordem abaixo é minha leitura didática da jornada, não uma sequência normativa extraída do repositório.

A folha começa em `Corporate Payroll Services`, domínio de padrão `Fulfill`, cuja ficha diz que ele processa pagamentos líquidos de salário para empregados de clientes corporativos. Ele recebe a instrução da folha. `Corporate Current Account`, também `Fulfill`, bloqueia o total na conta da empresa antes do primeiro crédito. Essa reserva é o ponto que separa uma arquitetura séria de uma fila otimista.

Depois, `Payment Confirmation` confere e reserva. `Payment Settlement` move os fundos, passando por `Internal Bank Account`, que é `Track` e funciona como conta intermediária. `Current Account` credita Marina, personagem fictícia. `Position Keeping`, também `Track`, registra a posição. `Correspondence`, de padrão `Operate`, avisa fora do caminho crítico.

A lição dura: folha é um lote de milhares de pagamentos pequenos. Use idempotência por crédito, evento com id do lote, reserva do total antes do primeiro crédito, e comunicação assíncrona para o aviso.

## Folha de pagamento interna no mapa v14

O desenho mostra a jornada com as duas trocas de nome obsoleto para o substituto usado nesta aula.

### 🏢 Empresa: origem da folha

- Corporate Payroll Services Fulfill (compute)
- Corporate Current Account Fulfill (data)

### 💳 Pagamento: confirmação e liquidação

- Payment Confirmation substitui Payment Order (security)
- Payment Settlement substitui Payment Execution (network)
- Internal Bank Account Track (data)

### 👤 Cliente: crédito e registro

- Current Account crédito da Marina (data)
- Position Keeping Track (storage)
- Correspondence Operate (messaging)

### Fluxos

- payroll -> corpAccount: instrução da folha
- corpAccount -> confirmation: reserva o total
- confirmation -> settlement: confere e reserva
- settlement -> internalAccount: move fundos pela conta intermediária
- internalAccount -> currentAccount: credita Marina
- currentAccount -> position: registra posição
- currentAccount -> notice: avisa fora do caminho crítico

> **Minha leitura:** Na prática, eu não trataria conta-salário como um domínio novo só porque o produto tem restrição regulatória própria. Eu modelaria as condições no `Product Directory`, aplicaria a regra no domínio da conta no momento do crédito, e trataria portabilidade salarial como `Standing Order`, de padrão `Fulfill`. O BIAN 14.0 não traz um domínio específico de conta-salário, e isso importa: inventar domínio para cada variação de produto deixa o mapa bonito no workshop e caro na manutenção.

## Conta-salário: o produto muda, a fronteira precisa continuar limpa

A Resolução CMN `5.058/2022` dá restrições concretas para conta-salário. Ela só aceita créditos da entidade contratante, no art. `3º`. Não movimenta por cheque, no art. `4º`. É vedada para titular pessoa jurídica, no art. `2º`, § `3º`. A portabilidade salarial acontece a pedido do beneficiário, no art. `7º`.

Essas regras não significam que você precisa criar um domínio chamado conta-salário no mapa. Eu procurei esse domínio na v14 e ele não aparece. A diferença está no produto, na elegibilidade, na origem aceita para crédito e na rotina de portabilidade, não numa nova capacidade universal de conta.

O erro clássico é colocar tudo em `Current Account` como exceção escondida. Isso funciona até alguém tentar auditar por que uma transferência foi recusada ou por que um crédito de origem errada entrou. A regra precisa estar modelada como produto, aplicada no ponto de crédito, e rastreável como decisão.

Quando o crédito vem de outro banco, o cenário oficial `Handle Incoming Credit Transfer`, view `55000`, usa `Correspondent Bank Operations`, `Payment Order` e `Payment Execution`, todos obsoletos. Nesta aula, leia `Payment Rail` no lugar de `Correspondent Bank Operations`, e mantenha `Regulatory Compliance` para a checagem de lavagem de dinheiro, indicada pela mensagem `Conduct AML Check`.

### Nome e status na v14

- **Direct Debit Collection** → Obsoleto
- **Direct Debits Service** → Obsoleto, sem substituto citado
- **Direct Debit** → Registrado (Fulfill)
- **Direct Debit Mandate** → Registrado (Catalog)
- **Customer Consent** → Novo, sem status
- **Payment Execution** → Obsoleto, substituto: Payment Settlement
- **Payment Settlement** → Novo, substitui o Payment Execution

## Boleto e Pix: mesma frente de orquestração, trilho diferente
| Dimensão | Boleto | Pix |
| --- | --- | --- |
| Trilho | Pagamento passa pelas instituições do arranjo, com base centralizada para registro e consulta dos boletos. | Usa SPI, com liquidação bruta em tempo real. |
| Diretório ou base | Base centralizada definida pela Resolução BCB `443/2024`. | DICT operado pelo Banco Central. |
| Tempo de operação | As regras desta aula cobrem liquidação e devoluções previstas na Resolução BCB `443/2024`. | Funciona `24` horas por dia. |
| Leitura arquitetural | Jornada adaptada da do Pix, com `Payment Order Initiation`, `Payment Orchestration`, `Payment Confirmation`, `Payment Rail`, `Payment Settlement` e `Current Account`. | A mesma frente de iniciação, orquestração, confirmação e liquidação fica mais direta porque o trilho já é o SPI. |

## Boleto: não existe domínio mágico, existe regra de trilho

A Resolução BCB `443/2024` define os papéis do boleto: beneficiário, pagador, instituição emissora, instituição recebedora, instituição destinatária e base centralizada, que serve como repositório para registro e consulta dos boletos. O `VR Boleto` é `R$ 250.000,00`, no art. `19`.

Quando o valor é igual ou superior ao `VR Boleto`, a transferência deve ocorrer no mesmo dia pelo STR, encaminhada para liquidação em até `60` minutos após o pagamento, conforme art. `16`, I e § `1º`. Abaixo desse valor, a recebedora pode usar compensação multilateral ou o procedimento do STR, conforme art. `16`, II. Devoluções e acertos detectáveis por automação devem ocorrer até o dia útil seguinte ao da liquidação, conforme art. `18`, § `1º`.

STR aqui não é detalhe de infraestrutura. É liquidação bruta em tempo real, irrevogável, sem saldo negativo. Essa frase muda desenho de risco, fila, retry e conciliação.

Minha leitura: pagar boleto é uma jornada adaptada da do Pix. A frente usa `Payment Order Initiation`, `Payment Orchestration` e `Payment Confirmation`, cuja ficha lista checagens de risco, incluindo lavagem de dinheiro (`AML`), e `Fraud Evaluation` testa o risco de fraude. Depois entram `Payment Rail`, `Payment Settlement` e `Current Account`. Emitir boleto, como não há domínio de boleto na v14, eu colocaria como desvio registrado em ADR, perto de `Cash Management And Account Services`, de padrão `Fulfill`, com recebimentos pelo `Payment Rail`.

## Nomes parecidos que eu validaria antes de qualquer desenho

- `Payment Order` e `Payment Execution` aparecem em cenários antigos, mas são obsoletos na v14.
- `Payment Confirmation` confirma e reserva. `Payment Settlement` liquida. Misturar os dois esconde estado operacional.
- `Direct Debit` registrado é o lado do credor e tem padrão `Fulfill`. `Direct Debit Mandate` registrado guarda os mandatos e tem padrão `Catalog`.
- `Direct Debit Collection` e `Direct Debits Service` são obsoletos na v14, sem substituto citado nas release notes.
- `Customer Consent` é novo e registra preferências e restrições do cliente para débitos e pedidos de pagamento.

## Débito automático: mandato, consentimento e lado do credor

Débito automático costuma ser ensinado como uma autorização simples. No mapa, eu separo três coisas: o serviço que executa pelo lado do credor, o mandato que prova a autorização, e o consentimento que expressa preferência e restrição do cliente.

Na v14, `Direct Debit Collection` e `Direct Debits Service` estão obsoletos, sem substituto citado nas release notes. O domínio registrado `Direct Debit` tem padrão `Fulfill` e fica no lado do credor. `Direct Debit Mandate` tem padrão `Catalog` e guarda os mandatos. `Customer Consent` é novo, sem padrão citado aqui, e registra preferências e restrições do cliente para débitos e pedidos de pagamento.

Globalmente, existe o cenário oficial `EXT Record Core SEPA Direct Debit Mandate at Creditor Bank`, view `55394`, para o esquema europeu. Eu não traria regra de SEPA para esta aula, porque o ponto didático é outro: mandato não é cobrança, consentimento não é liquidação, e trilho não é produto.

Se você colocar tudo num único serviço chamado débito automático, o sistema até passa no demo. A primeira auditoria pede quem autorizou, qual consentimento estava vigente, qual cobrança usou o mandato, e qual trilho liquidou. Sem essas fronteiras, a resposta vira busca em log.

## Segunda de manhã

1. **Modele um `Payment Rail` por trilho**: Coloque a mesma frente de orquestração antes do trilho: iniciação, confirmação, checagens e liquidação. O que muda é a regra do trilho, não a intenção do pagamento.

2. **Transforme regra normativa em configuração explícita**: `VR Boleto` e o limite de `60` minutos não devem ficar enterrados em código de aplicação. Eles pertencem à configuração do trilho, com versionamento e trilha de auditoria.

3. **Registre todo desvio do mapa em ADR**: Se emitir boleto ficou perto de `Cash Management And Account Services`, escreva a decisão, a alternativa recusada e o risco aceito. Desvio sem ADR vira arquitetura oral.

4. **Valide nomes parecidos no pipeline**: Faça o validador recusar `Direct Debit Collection` quando a versão alvo for BIAN 14.0. O mesmo vale para `Payment Order` e `Payment Execution`. Falha silenciosa aqui vira contrato errado.

### Checagem rápida

1. **Pela Resolução BCB 443/2024, como pode liquidar um boleto de R$ 120.000,00?**
- [x] Por compensação multilateral ou pelo STR, a critério da recebedora, _Está abaixo do VR-Boleto de R$ 250.000,00._
- [ ] Obrigatoriamente pelo STR em até 60 minutos, _Isso vale para valor igual ou acima do VR-Boleto._
- [ ] Pelo SPI, em tempo real, _O SPI é o trilho do Pix._
- [ ] A critério do pagador, _A escolha é da instituição recebedora._

2. **Qual destas é regra da conta-salário pela Resolução CMN 5.058/2022?**
- [x] Só aceita créditos da entidade contratante, _E o beneficiário tem direito à portabilidade salarial._
- [ ] Pode ter pessoa jurídica como titular, _É vedado._
- [ ] Movimenta por cheque, _Não movimenta por cheque._
- [ ] Tem um Service Domain próprio na v14, _Não existe domínio de conta-salário; o mapeamento é composição._

## Perguntas rápidas

### BIAN define uma ordem oficial para cada seta dessas jornadas?

Não nesta aula. O repositório lista linhas de vida dos cenários. A ordem narrada aqui é minha leitura para ensinar a arquitetura, usando os nomes e estados permitidos pela v14.

### Por que não criar um domínio de boleto?

Porque a v14 não traz esse domínio. Minha leitura é tratar emissão como desvio documentado perto de `Cash Management And Account Services` e recebimento pelo `Payment Rail`. O ADR existe para não fingir que o mapa disse algo que não disse.

### O que a IA Builder faz nesse pedaço?

Ela rascunha o mapeamento e os contratos com grounding nas definições oficiais, aponta nomes obsoletos, e mede divergência. A decisão continua humana, porque portabilidade, boleto e débito automático carregam regra regulatória e risco operacional.

## Veredito

Eu desenharia salário, boleto e débito automático com uma frente comum de pagamento e trilhos explícitos. A fronteira que importa não é o nome popular do produto, é onde a regra muda: reserva antes do crédito, liquidação pelo STR, mandato, consentimento, AML, fraude e aviso fora do caminho crítico. Use o mapa do BIAN 14.0 como contrato de linguagem, mas registre em ADR onde o mercado brasileiro exige uma leitura própria.

### 13. Cartão, crédito e cobrança

_Quem é dono de uma disputa, de uma decisão de crédito e de um atraso._

Cartão, crédito e cobrança parecem morar na mesma gaveta porque aparecem juntos na vida do cliente. Na arquitetura eles não são a mesma coisa. A pergunta útil nesta aula não é “qual sistema atende isso?”, é “quem é dono da decisão, quem só consulta dados, e quem pode mudar o estado financeiro?”

## A disputa da Marina começa pela classificação

Marina é fictícia. Ela comprou um fone, o produto nunca chegou, e ela reclama no canal do banco. Isso é uma disputa comercial, não um golpe. Essa classificação vem antes do caso, porque abrir o caso errado contamina o fluxo inteiro.

No cenário oficial `Handle Card Chargeback at Issuer`, view `55690`, o repositório lista as linhas de vida: Correspondence, Card Clearing, Credit Card, Customer Case, Operational Gateway, Card Case, Card Transaction Capture, Card Network Participant Facility e Session Dialogue. A ordem que eu uso para explicar o fluxo é esta: Session Dialogue recebe a reclamação; Card Case abre o caso; Credit Card traz a cobrança; Card Clearing recupera a transação; Card Network Participant Facility consulta as regras da bandeira; Operational Gateway pede informação ao adquirente; se procede, Card Transaction Capture inicia o chargeback; Correspondence responde.

O ponto de arquitetura é simples: Card Case é o dono do processo de disputa. Ele tem 17 operações no YAML v14 e Behavior Qualifiers como Consolidation, Chargeback, Arbitration e Resolution, com operationIds `Initiate`, `UpdateChargeback`, `ExchangeArbitration` e `UpdateResolution`. Isso não transforma Card Case em dono da compra, da autorização, da fatura ou da comunicação. Ele coordena o caso.

## Três casos, três donos

- **Card Case:** disputa de cartão, chargeback e arbitragem. Use quando a reclamação nasce de uma cobrança de cartão e precisa seguir o processo da disputa.
- **Customer Case:** problemas que pedem resposta corretiva a uma transação financeira. Use quando o foco é atendimento e correção, não a mecânica de chargeback.
- **Fraud Resolution:** abre e processa caso de fraude, define responsabilidade e inicia reversões. Use quando o problema é fraude, não desacordo comercial.
- **Regra prática:** classifique a reclamação antes de abrir o caso. O canal pode ser o mesmo, mas o domínio dono muda.

> **Leitura de arquiteto:** Na prática, eu trato cartão como uma sequência de responsabilidades pequenas. Card Authorization avalia, Card Transaction Capture transaciona, Card Clearing processa, Card Financial Settlement liquida, Customer Billing fatura. Quando a disputa aparece, Card Case não reescreve essa história. Ele aponta para ela, coleta evidência e conduz o processo.

### Quem é o dono?

1. **A Marina contesta uma compra no cartão porque o produto nunca chegou. Qual domínio é dono do caso?**
- [x] Card Case, _Disputa de cartão, com chargeback e arbitragem._
- [ ] Fraud Resolution, _É disputa comercial, não fraude._
- [ ] Customer Case, _Cuida de correção de transação, não de chargeback._
- [ ] Card Authorization, _Decide a autorização em tempo real, não a disputa._

2. **Quando termina o Delinquent Account Handling, segundo a ficha?**
- [x] Quando a conta é cancelada e transferida para Collections, _Conta ativa com risco e conta encerrada têm donos diferentes._
- [ ] No primeiro lembrete enviado, _O lembrete é um passo, não o fim._
- [ ] Quando o Customer Billing emite a fatura, _A fatura vem antes do atraso._
- [ ] Nunca; ele cuida também da venda da dívida, _Venda da dívida é do Collections._

## Crédito pessoal: quem decide consulta, não guarda tudo

No crédito pessoal sem garantia, três cenários ajudam a separar as responsabilidades: `Handle Request for Uncollateralised Consumer Loan`, view `55503`; `Perform Underwriting for Uncollateralised Consumer Loan`, view `55150`; e `Disburse Uncollateralised Consumer Loan`, view `54814`. O último ainda lista Payment Order, que é obsoleto no BIAN 14.0.

Antes de o Underwriting decidir, ele consulta Customer Position, Customer Credit Rating, Fraud Evaluation, Credit Risk Models e Regulatory Compliance. Essa frase vale ouro em arquitetura: quem decide não precisa virar um depósito de todos os dados que consultou. Underwriting cria a avaliação com `Evaluate`, em `POST /Underwriting/Evaluate`, e concede com `Grant`. Customer Offer orquestra a oferta e tem 34 operações, mas não deve virar o monólito do crédito.

Consumer Loan é o domínio que cumpre o contrato, com 29 operações. Na Semantic API v14, o desembolso aparece dentro de Consumer Loan só como `Retrieve`, em `GET .../Disbursement/{id}/Retrieve`. Quem inicia e executa o desembolso é Disbursement, com `POST /Disbursement/Initiate` e `PUT /Disbursement/{id}/Execute`. Já o pagamento da parcela acontece dentro de Consumer Loan, no qualifier Repayment, com `PUT .../Repayment/{id}/Execute`. Essa diferença evita um erro caro: fazer o contrato do empréstimo executar dinheiro.

## Pedido de crédito sem virar monólito

O desenho separa oferta, decisão, dados consultados, contrato e desembolso. A linha grossa é comando. A linha pontilhada é leitura para decisão.

### 👤 Cliente: pedido

- Cliente solicita crédito (user)

### 🔧 Originação: oferta

- Customer Offer orquestra a oferta (compute)

### 🤖 Decisão: avaliação

- Underwriting Evaluate e Grant (ai)

### 📚 Consultas: evidência

- Customer Position posição do cliente (data)
- Customer Credit Rating classificação de crédito (data)
- Fraud Evaluation avalia fraude (security)
- Credit Risk Models modelos de risco (data)
- Regulatory Compliance avalia conformidade (security)

### 🏦 Contrato: execução

- Consumer Loan contrato e Repayment (compute)
- Disbursement Initiate e Execute (messaging)

### Fluxos

- client -> offer: pede proposta
- offer -> underwriting: solicita avaliação
- underwriting -> position: consulta
- underwriting -> rating: consulta
- underwriting -> fraud: consulta
- underwriting -> models: consulta
- underwriting -> compliance: consulta
- underwriting -> loan: concede
- loan -> disbursement: pede desembolso
- disbursement -> loan: resultado recuperável

## Brasil: SCR, LGPD e perda esperada entram como fatos auditáveis

No Brasil, crédito sem governança vira passivo regulatório. Segundo o Banco Central, o SCR mantém registro individualizado do cliente com risco igual ou superior a R$ 200,00, alimentado mensalmente pelas instituições. A consulta aos dados consolidados exige autorização do cliente. No mapa, eu trataria essa autorização como registro auditável, com data e finalidade, porque autorização sem rastro vira discussão de evidência.

A Resolução CMN 4.966/2021 traz instrumentos financeiros em primeiro, segundo e terceiro estágios de perda esperada. Os demais dispositivos têm vigência desde 1º de janeiro de 2025. A leitura operacional é direta: quem calcula o estágio publica o fato, e a contabilidade consome. A contabilidade não deveria recalcular a decisão escondida dentro de outro domínio.

A LGPD art. 20 também muda o desenho. Se há revisão de decisão automatizada, a decisão precisa guardar a versão do modelo. Não basta gravar “aprovado” ou “negado”. Guarde a versão usada, as entradas relevantes permitidas e o rastro mínimo para explicar a decisão. No financiamento imobiliário, a separação fica ainda mais visível: Mortgage Loan cumpre o contrato, com 47 operações e o qualifier CollateralAllocation; Collateral Asset Administration administra o bem; Collateral Allocation Management aloca a garantia.

## Cobrança: leitura ampla, escrita estreita

1. **Customer Billing sinaliza a parcela não paga**: A origem do atraso vem da cobrança ao cliente. Esse domínio aponta o fato, ele não precisa resolver toda a vida da conta.

2. **Open Item Management abre o item em aberto**: O atraso vira item tratável. Isso separa saldo, fatura e exceção operacional.

3. **Delinquent Account Handling define a estratégia de contato**: A ficha do domínio diz: `This process ends when the account is cancelled and is transferred to Collections`. Para mim, essa frase define a fronteira.

4. **Correspondence envia o lembrete**: Comunicação é comunicação. Ela executa a mensagem, não decide o estágio da conta.

5. **Customer Case abre caso de conta em dificuldade**: No cenário `Resolve a Missed Payment`, view `54728`, a mensagem é `Initiate Distressed A/C Case`. O caso organiza a resposta ao cliente.

6. **Collections cuida da recuperação**: Collections trata recuperação, liquidação de garantias e venda da dívida. A regra é um domínio mudar o estado da conta em cada estágio.

## Quem é dono do quê
| Situação | Domínio dono | Domínios vizinhos | Risco se misturar |
| --- | --- | --- | --- |
| Disputa comercial de cartão | Card Case | Credit Card, Card Clearing, Card Transaction Capture, Correspondence | Tratar desacordo comercial como fraude ou como atendimento genérico. |
| Decisão de crédito pessoal | Underwriting | Customer Position, Customer Credit Rating, Fraud Evaluation, Credit Risk Models, Regulatory Compliance | Guardar todos os dados no decisor e perder a fronteira de responsabilidade. |
| Desembolso do empréstimo | Disbursement | Consumer Loan | Fazer o contrato executar dinheiro diretamente. |
| Cobrança de atraso | Delinquent Account Handling, depois Collections | Customer Billing, Open Item Management, Correspondence, Customer Case | Vários domínios mudando o estado da conta ao mesmo tempo. |

### A cobrança pelos cenários oficiais

Ordene do atraso da parcela à recuperação.

1. Customer Billing sinaliza a parcela não paga
2. Open Item Management abre o item em aberto
3. Delinquent Account Handling define a estratégia
4. Correspondence envia o lembrete
5. Customer Case abre o caso de conta em dificuldade
6. Collections cuida da recuperação

## Perguntas que destravam o mapa

### Card Case substitui Customer Case?

Não. Card Case é específico para disputa de cartão, chargeback e arbitragem. Customer Case cobre problemas que pedem resposta corretiva a uma transação financeira. A classificação vem antes da abertura.

### Underwriting deve copiar todos os dados que consulta?

Não como regra. Ele precisa registrar a decisão, a versão do modelo quando houver decisão automatizada, e a evidência necessária para auditoria. Os domínios de posição, rating, fraude, modelo e conformidade continuam sendo vizinhos consultados.

### Collections começa no primeiro atraso?

Não necessariamente. Nos cenários usados aqui, Customer Billing sinaliza, Open Item Management abre o item, Delinquent Account Handling define contato, e Collections entra na recuperação. A transferência para Collections é uma mudança de estágio, não um detalhe de tela.

## Veredito

Use BIAN 14.0 aqui como mapa de responsabilidade, não como catálogo para renomear sistemas. Em cartão, classifique a reclamação antes do caso. Em crédito, deixe Underwriting decidir com leitura dos vizinhos e Disbursement executar o dinheiro. Em cobrança, aplique leitura ampla e escrita estreita: muitos domínios podem observar, mas um domínio muda o estado da conta em cada estágio.

### 14. Investimentos, fraude e lavagem de dinheiro

_Um falso amigo no investimento, quatro domínios de fraude e os prazos da prevenção à lavagem de dinheiro._

Investimento, fraude e lavagem de dinheiro parecem morar no mesmo andar do banco, mas operam com relógios diferentes. Investimento começa com intenção e contrato. Fraude decide sob pressão, antes que o dinheiro suma. Lavagem exige análise, dossiê e prazo formal.

## Investimento começa com pedido, não com produto

No cenário oficial `Handle Request for Investment Plan`, view 55657, a ordem que uso para ensinar é simples. `Session Dialogue` recebe o pedido. `Party Lifecycle Management` verifica a parte. `Customer Position`, de padrão Monitor, traz a posição consolidada. `Investment Portfolio Planning`, de padrão `Agree Terms`, prepara o plano. `Suitability Checking` verifica a adequação do produto pela mensagem `Verify Product Suitability`. Depois `Sales Product Agreement` cria o contrato, `Investment Account` abre a conta de investimento, e `Current Account` abre a conta de caixa ligada com `Pre-Open Investment Cash Account`.

A armadilha está no nome. A Resolução CVM 30/2021 trata do dever de verificar a adequação de produtos, serviços e operações ao perfil do cliente. Esse é o suitability brasileiro. A ficha do `Suitability Checking`, porém, diz outra coisa: confirmar se todas as contrapartes envolvidas são adequadas para uma operação de mercado proposta. Nome parecido não é escopo igual.

Na prática, o perfil do cliente precisa de dono, validade e rastreabilidade. Cada recomendação guarda o perfil vigente usado na decisão. Se você só joga tudo em `Suitability Checking`, perde a prova operacional que vai importar quando alguém perguntar por que aquele produto foi recomendado naquele dia.

> **Leitura minha:** Na prática, eu separo o nome comercial do comportamento bancário. O BIAN não conhece o nome CDB. Um CDB com vencimento entra em `Term Deposit` pelo comportamento: valor fixo, prazo fixo, juros, abertura, manutenção e vencimento. O nome comercial fica no `Product Directory`. A decisão de mapeamento precisa ser registrada, porque é ela que protege a arquitetura quando produto, jurídico e tecnologia usam palavras diferentes.

## A espinha do investimento

A espinha do investimento fica mais clara quando você para de procurar telas e começa a procurar responsabilidades. `Investment Account` cumpre a conta de investimento. `Consumer Investments` transaciona pedidos de compra e venda. `Market Order` acompanha a ordem. `Securities Position Keeping` rastreia a posição de valores mobiliários. `Term Deposit` cumpre a conta remunerada por valor fixo e prazo fixo.

Essa separação evita uma confusão comum em bancos com muitos produtos. O produto vendido ao cliente pode ter nome de campanha, variação tributária, canal específico e regra operacional própria. O mapa funcional não deve virar catálogo comercial. Ele deve responder quem mantém o contrato, quem acompanha a ordem, quem sabe a posição e quem guarda a evidência de adequação.

Use `Investment Account` quando a pergunta for conta de investimento. Use `Consumer Investments` quando a pergunta for pedido de compra ou venda. Use `Market Order` quando a pergunta for acompanhamento da ordem. Use `Securities Position Keeping` quando a pergunta for posição. Use `Term Deposit` quando o comportamento for depósito a prazo. Se a discussão começa pelo nome do produto, traga a conversa de volta para o comportamento que precisa ser operado e auditado.

### Os quatro domínios de fraude

- **Fraud Model (Design)**: Desenha e mantém os modelos de fraude.
- **Fraud Evaluation (Assess)**: Testa cada transação contra regras e modelos e dá um veredito pontual.
- **Fraud Diagnosis (Analyse)**: Avalia o que foi detectado para conter a exposição.
- **Fraud Resolution (Process)**: Abre o caso, investiga, define responsabilidade e inicia reversões.

## Fraude em ciclo, MED em composição

O MED não vira um domínio próprio no mapa. Ele aparece como uma composição entre avaliação, caso, diagnóstico, resolução, trilho de pagamento e aprendizado do modelo.

### 🔐 Fraude: ciclo de decisão

- Fraud Model modelos e regras (ai)
- Fraud Evaluation pontua a transação (security)
- Fraud Diagnosis analisa a exposição (security)
- Fraud Resolution caso, responsabilidade e reversão (compute)

### 👤 Cliente: pedido MED

- Vítima ligação falsa da central (user)
- Customer Case pedido registrado (data)

### 📡 Pix: trilho e resposta

- Payment Rail mensagens entre instituições (network)
- Conta do recebedor bloqueio temporário possível (external)

### Fluxos

- victim -> case: registra pedido em até 80 dias
- case -> fraud-diag: abre análise
- fraud-model -> fraud-eval: fornece regras e modelo
- fraud-eval -> fraud-diag: sinal suspeito
- fraud-diag -> fraud-res: exposição e evidência
- fraud-res -> payment-rail: pede devolução
- payment-rail -> receiver: bloqueio e troca de mensagens
- fraud-res -> fraud-model: resultado do caso treina o ciclo

## Fraude decide rápido, lavagem decide com dossiê

Na fraude, eu penso em quatro domínios. `Fraud Model` desenha e mantém modelos. `Fraud Evaluation` testa transações contra regras e modelos. `Fraud Diagnosis` avalia o que foi detectado para conter exposição. `Fraud Resolution` abre o caso, investiga, define responsabilidade e inicia reversões.

A cena fictícia é conhecida: Marina recebe uma ligação falsa da central do banco e faz um Pix para uma suposta conta de segurança. Segundo a página de segurança do Pix do Banco Central, o MED é ferramenta exclusiva do Pix para vítimas de fraude. O pedido pode ser feito em até 80 dias após a transação. Os recursos do recebedor são bloqueados temporariamente e o caso é analisado pelas instituições. O ponto que precisa ficar escrito no desenho: O MED não garante a devolução. Também existe bloqueio cautelar em caso de suspeita.

Minha leitura: o MED não tem domínio próprio. Ele vira composição. `Fraud Evaluation` pontua o Pix suspeito. `Customer Case` registra o pedido da vítima. `Fraud Diagnosis` analisa. `Fraud Resolution` decide e pede a devolução. `Payment Rail` troca as mensagens. `Fraud Model` aprende com o resultado do caso. Sem essa volta, o modelo envelhece em silêncio.

## Fraude versus lavagem de dinheiro
| Dimensão | Fraude | Lavagem de dinheiro |
| --- | --- | --- |
| Relógio operacional | Decisão em tempo real, com contenção de exposição. | Análise formal com prazo, evidência e dossiê. |
| Dono típico | Times de fraude, operações e canais de pagamento. | Prevenção à lavagem de dinheiro e conformidade regulatória. |
| BIAN no desenho | `Fraud Model`, `Fraud Evaluation`, `Fraud Diagnosis`, `Fraud Resolution`. | Aparece em pontos como `Payment Confirmation`, `Regulatory Compliance` e `Financial Message Analysis`. |
| Falha clássica | Bloquear sem caso, ou avaliar sem devolver o resultado ao modelo. | Misturar com fraude no mesmo motor sem dono claro do dossiê. |

## Lavagem tem prazo, dossiê e limite para terceirização

A Circular BCB 3.978/2020 muda o tom da conversa. Os arts. 38 e 39 tratam de monitorar e selecionar operações suspeitas. O art. 43, § 1º, exige análise em no máximo 45 dias a partir da seleção. O § 2º exige formalização em dossiê. O art. 48, § 2º, exige comunicação ao Coaf até o dia útil seguinte ao da decisão de comunicar. O art. 44 veda contratar terceiros para a análise e veda a análise no exterior, mas permite serviços auxiliares.

Isso define o papel da IA. Um modelo pode resumir, ordenar e sugerir. A análise e a decisão ficam com o analista, registradas no dossiê. A pergunta correta não é se a IA encontrou um alerta, é quem assina a decisão, onde a evidência fica guardada e como o prazo é medido.

No mapa conferido, a checagem de lavagem aparece em três lugares. `Payment Confirmation` cita `Risk Checks (AML, Credit, Fraud, Operational)`. `Regulatory Compliance` aparece nos cenários de crédito recebido pela mensagem `Conduct AML Check`. `Financial Message Analysis` acompanha e analisa tráfego de mensagens financeiras para identificar anomalias e atividade potencialmente fraudulenta. Fraude e lavagem podem tocar o mesmo fluxo de pagamento, mas não devem perder seus donos.

## O que você deve levar para o desenho

- Não use nome comercial como domínio. Mapeie pelo comportamento e registre a decisão.
- Separe suitability brasileiro, perfil do cliente e `Suitability Checking`. Nome parecido não prova escopo igual.
- Modele o MED como composição. O Pix suspeito, o caso da vítima, a análise e a devolução têm responsabilidades diferentes.
- Mantenha lavagem de dinheiro com dono, prazo e dossiê. IA ajuda, mas não substitui a decisão formal.

### Verdadeiro ou falso, em quatro opções

1. **Pela ficha da v14, o que o Suitability Checking confirma?**
- [x] Que as contrapartes são adequadas a uma operação de mercado proposta, _É um falso amigo do suitability da CVM 30._
- [ ] O perfil de risco do investidor exigido pela CVM 30, _A ficha não fala de perfil do investidor._
- [ ] O consentimento do cliente no Open Finance, _Isso é Customer Consent._
- [ ] A liquidez do banco, _Isso é Corporate Treasury._

2. **O que é verdade sobre o MED, segundo o Banco Central?**
- [x] O pedido vai até 80 dias após a transação e a devolução não é garantida, _Depende da análise e de existir saldo bloqueado._
- [ ] Garante a devolução integral em 80 dias, _A página diz que o MED não garante a devolução._
- [ ] Vale para boleto e cartão, _É exclusivo do Pix._
- [ ] É um Service Domain da v14, _No mapa, o MED é composição de domínios._

3. **Pela Circular 3.978, qual o prazo máximo para analisar uma operação selecionada como suspeita?**
- [x] 45 dias a partir da seleção, _E a análise é formalizada em dossiê._
- [ ] O dia útil seguinte à seleção, _O dia útil seguinte é o prazo da comunicação ao Coaf, contado da decisão._
- [ ] 80 dias, _80 dias é o prazo de pedido do MED._
- [ ] Não há prazo, _O art. 43 fixa o prazo._

4. **A análise de operações suspeitas pode ser contratada de terceiros no exterior?**
- [x] Não; o art. 44 veda terceirizar a análise e fazê-la no exterior, _Serviços auxiliares à análise são permitidos._
- [ ] Sim, se o fornecedor for certificado, _A vedação não tem essa exceção._
- [ ] Sim, se um modelo de IA fizer a análise, _A análise e a decisão ficam com o analista da instituição._
- [ ] Só para operações em espécie, _A vedação vale para a análise das operações selecionadas._

5. **Qual é o padrão funcional do Fraud Model?**
- [x] Design, _Desenha e mantém os modelos._
- [ ] Assess, _Assess é o Fraud Evaluation._
- [ ] Analyse, _Analyse é o Fraud Diagnosis._
- [ ] Process, _Process é o Fraud Resolution._

## Perguntas que aparecem na arquitetura

### Posso tratar fraude e lavagem no mesmo motor?

Você pode compartilhar sinais e infraestrutura, mas não deve apagar os donos. Fraude decide em tempo real. Lavagem exige seleção, análise em até 45 dias, dossiê e decisão formal.

### Onde coloco o aprendizado do caso de fraude?

Feche o ciclo em `Fraud Model`. Se `Fraud Resolution` decide o caso e esse resultado nunca volta ao modelo, a avaliação continua repetindo erros antigos.

### CDB é `Term Deposit` sempre?

Não por nome. Nesta leitura, um CDB com vencimento é mapeado para `Term Deposit` pelo comportamento descrito: valor fixo, prazo fixo, juros, abertura, manutenção e vencimento. Registre a decisão.

## Veredito

A arquitetura correta aqui não é juntar investimento, fraude e lavagem em uma plataforma genérica de risco, é preservar o relógio e o dono de cada decisão. Investimento precisa de contrato, conta, posição e evidência de adequação. Fraude precisa de ciclo rápido com resultado voltando ao modelo. Lavagem precisa de seleção, análise, dossiê, prazo e decisão humana responsável.

## Módulo 5: O BIAN no trabalho, parte 2

Bastidores e cliente 360, oito técnicas para a segunda-feira, seis realidades de instituição, dois casos fictícios e IA no banco inteiro.

### 15. Bastidores e cliente 360

_Do evento ao relatório regulatório, a tesouraria e uma visão 360 por composição, sem cópia de dados._

A parte mais invisível de um banco costuma ser a que mais cobra precisão: sair de um evento de produto, passar por posição, contabilidade, conciliação, tesouraria e reporte, sem perder a referência original. A pergunta perigosa não é se a tela mostra um saldo bonito, é se você consegue voltar do relatório regulatório ao evento que criou aquele número. Nesta aula eu junto bastidores e cliente 360 porque os dois expõem a mesma disciplina: cada domínio tem dono, finalidade e rastro.

## Do evento ao relatório, sem misturar posição com contabilidade

O caminho começa no produto. No BIAN 14, o Position Keeping, de padrão Track, mantém o log das transações postadas em cada produto. A própria ficha diz que transações financeiras reconciliadas são usadas depois para postagem nos sistemas contábeis. Essa frase é pequena, mas muda o desenho.

Posição de produto não é contabilidade, é o registro operacional daquele produto. Financial Accounting, também com padrão Track, recebe fatos financeiros e cria instruções contábeis que atualizam razão geral e razões auxiliares. Account Reconciliation, com padrão Process, concilia. Bank Portfolio Administration consolida e apresenta informação para o book of business do banco. Regulatory Reporting, com padrão Administer, cuida das obrigações de reporte regulatório.

A confusão mais cara que vejo em desenhos bancários é tratar posição do produto como contabilidade. Se o mesmo sistema faz os dois papéis, mudar o plano de contas vira mudar o sistema de conta. O problema não aparece no primeiro release. Ele aparece quando auditoria, regulador, conciliação e produto querem ritmos diferentes de mudança.

> **Minha leitura:** Na prática, eu trato cada número regulatório como uma trilha em cinco paradas: evento do produto, posição, lançamento, conciliação e relatório. Cada parada guarda a referência da anterior. Se a referência quebra, você ainda pode ter um relatório bonito, mas perde a capacidade de explicar o número sob pressão.

## Trilha operacional: do evento ao regulador e ao cliente 360

O mesmo evento alimenta a cadeia contábil e regulatória, enquanto a visão 360 compõe leituras dos donos certos sem copiar tudo para um banco único.

### 📦 Produto: origem do fato

- Evento do produto fato financeiro (compute)
- Position Keeping transações postadas (data)

### 📘 Contábil: lançamento e prova

- Financial Accounting instrução contábil (data)
- Account Reconciliation conciliação (compute)

### 🏦 Banco: visão institucional

- Bank Portfolio Administration book of business (data)
- Regulatory Reporting obrigações regulatórias (external)

### 👤 Cliente: composição 360

- Customer Position posição consolidada (data)
- Customer Event History histórico de eventos (data)
- Party Routing Profile indicadores e alertas (security)
- Tela 360 compõe leituras (frontend)

### Fluxos

- event -> position: posta transação
- position -> accounting: gera fato para lançamento
- accounting -> reconciliation: concilia com referência
- reconciliation -> portfolio: alimenta visão do banco
- portfolio -> regreport: reporta obrigação
- position -> customerposition: compõe posição do cliente
- event -> eventhistory: registra o que aconteceu
- routingprofile -> screen: orienta atendimento
- customerposition -> screen: leitura com finalidade
- eventhistory -> screen: contexto do caso

## Tesouraria é controle de sobrevivência, não painel bonito

Corporate Treasury, com padrão Manage, existe para garantir liquidez do banco, gerir atividades táticas de funding e determinar e publicar taxas de juros e câmbio do banco. Asset And Liability Management, com padrão Direct, define políticas de ativos e passivos. Gap Analysis trabalha com fluxos de caixa projetados para risco de moeda e juros. Liquidity Risk Models cobre modelos de risco de liquidez, incluindo gap de liquidez e Liquidity at Risk.

Aqui o número importa. No Brasil, a Resolução 4.401/2015 está vigente para LCR. O LCR é o estoque de ativos de alta liquidez, HQLA, dividido pelas saídas líquidas de caixa previstas para 30 dias. Ele se aplica a bancos múltiplos, comerciais, de investimento, de câmbio e caixas econômicas com ativo total acima de R$ 100 bilhões, ou integrantes de conglomerado prudencial acima disso. A metodologia está na Circular 3.749/2015. A origem é Basileia III, BCBS, 2013, com mínimo de 100% a partir de 1º de janeiro de 2019.

O erro operacional é calcular indicador de liquidez em vários lugares com regras diferentes. Quando a crise chega, ninguém discute arquitetura conceitual. Discute qual número vale.

## Cliente 360 por composição, não por cópia

Imagine a Marina, fictícia, ligando para a central por causa de uma tarifa. Contact Handler recebe a interação. Party Authentication autentica. Party Routing Profile monitora um pequeno perfil de indicadores chave, com status como conta em atraso e alertas como possível fraude. Session Dialogue conduz a conversa. Customer Position mostra a posição financeira consolidada da cliente, combinando detalhes de produtos e serviços em uso. Customer Event History mostra o que aconteceu. Servicing Order executa o estorno da tarifa.

Há dois jeitos de construir a tela. O primeiro é copiar tudo para um banco com tudo e dono de nada. Ele nasce útil e fica desatualizado no dia seguinte. O segundo é compor. Customer Position, Customer Event History e Party Routing Profile continuam donos das suas leituras. A tela junta o que precisa para aquele atendimento, e a escrita acontece por pedido, como Servicing Order.

LGPD não é rodapé jurídico aqui. A Lei 13.709/2018 exige finalidade e necessidade no art. 6º, I e III, direitos do titular no art. 18, e registro das operações de tratamento no art. 37. Cada leitura de dado pessoal precisa carregar a finalidade. Esse detalhe separa cliente 360 de cópia indiscriminada.

### Necessidade e domínio

- **Log das transações por produto** → Position Keeping
- **Lançamento no razão** → Financial Accounting
- **Relatório ao regulador** → Regulatory Reporting
- **Garantir a liquidez do banco** → Corporate Treasury
- **Posição consolidada do cliente** → Customer Position
- **Alertas para rotear a ligação** → Party Routing Profile

## O que guardar para desenhar depois

- Pergunte sempre se dá para voltar do relatório ao evento. Sem essa pergunta, o desenho vira consolidação sem prova.
- Separe posição do produto, lançamento contábil e relatório regulatório. Eles mudam por razões diferentes.
- Centralize a regra do indicador de liquidez. Várias implementações do mesmo cálculo criam várias verdades.
- Construa cliente 360 por composição. A tela lê dos donos certos e escreve por pedidos explícitos.
- Trate finalidade como dado operacional. Para dado pessoal, ela acompanha a leitura, não aparece só no documento de privacidade.

## Cópia contra composição no cliente 360
| Dimensão | Cópia centralizada | Composição por domínio |
| --- | --- | --- |
| Dono do dado | Um banco concentra tudo e vira dono de nada. | Cada domínio mantém sua responsabilidade original. |
| Atualidade | Depende de sincronização, carga e reconciliação extra. | A tela lê a fonte certa no momento do atendimento. |
| LGPD | Finalidade tende a se perder depois da cópia. | Cada leitura pode carregar finalidade, necessidade e registro. |
| Escrita | Risco de atualização lateral fora do domínio dono. | Mudança entra por pedido explícito, como Servicing Order. |

## Três verificações antes de aprovar o desenho

1. **Siga uma transação até o relatório**: Escolha um evento de produto e peça as cinco referências: evento, posição, lançamento, conciliação e relatório.

2. **Ache a regra única de liquidez**: Se LCR aparece em vários sistemas com fórmulas diferentes, você não tem governança de liquidez, tem disputa de planilha.

3. **Teste a finalidade da tela 360**: Para cada leitura de dado pessoal, peça a finalidade. Se ninguém responde, a composição virou cópia com interface melhor.

## Dúvidas que aparecem na arquitetura

### Regulatory Reporting, Compliance Reporting e Regulatory And Legal Authority são a mesma coisa?

Não. Regulatory Reporting cuida de obrigações de reporte regulatório, como o envio mensal ao SCR, documento 3040. Compliance Reporting trata reporte de controles internos e auditoria. Regulatory And Legal Authority gerencia o relacionamento com reguladores e órgãos de governo.

### Onde entram modelos e insights do cliente?

Separe modelo de uso. Customer Behavior Models desenha modelos. Customer Behavior Insights analisa scores e eventos de vida. Channel Activity Analysis analisa atividade de canal, com qualificadores como CustomerFraud e Bot. Customer Financial Insights, novo na v14, analisa o histórico financeiro para oportunidades ou sinais de dificuldade.

### Checagem rápida

1. **Pela Resolução 4.401/2015, o LCR se aplica a quais bancos?**
- [x] Aos que têm ativo total acima de R$ 100 bilhões, _Ou em conglomerado prudencial acima desse valor._
- [ ] A todas as instituições autorizadas pelo BC, _A regra tem corte de porte._
- [ ] Só a cooperativas de crédito, _Cooperativas não estão na lista do art. 3º._
- [ ] A bancos com ativo acima de R$ 10 bilhões, _O corte é R$ 100 bilhões._

2. **Qual desenho de cliente 360 o curso recomenda?**
- [x] Composição: a tela lê dos donos e escreve só por pedidos, _Cada dado continua com um dono, e a LGPD fica mais simples._
- [ ] Uma base única com cópia de tudo, _Dona de nada, desatualizada no dia seguinte._
- [ ] Party Routing Profile com todos os dados do cliente, _A ficha fala em um perfil pequeno de indicadores._
- [ ] O Position Keeping como fonte do 360, _Ele registra por produto; a posição consolidada é do Customer Position._

## Veredito

Use BIAN aqui como mapa de responsabilidade, não como desenho de tela. Se o banco consegue explicar um relatório voltando ao evento, calcular liquidez por uma regra governada e montar cliente 360 por composição com finalidade explícita, o desenho está no caminho certo. Se precisa copiar tudo para entender tudo, a arquitetura ainda está pagando conveniência com auditoria futura.

### 16. Técnicas da segunda-feira e seis realidades

_Oito técnicas para usar o mapa no trabalho e como adaptá-las do banco grande à instituição de pagamento._

Na segunda de manhã, o BIAN só vale alguma coisa se ajudar você a tomar uma decisão melhor antes do próximo comitê, da próxima integração ou da próxima migração. A pergunta não é “temos um mapa bonito?”, é “sabemos quem escreve qual registro, qual contrato expõe isso e qual mudança quebra o banco?”.

## Oito técnicas, quatro pares

Eu organizo o uso prático do BIAN em quatro pares: mapa, fronteiras, contratos e mudança. Isso evita transformar o Service Landscape 14 em uma parede de nomes.

O primeiro par é mapa. Comece com mapeamento de capacidades: inventarie o que cada sistema faz de verdade, levante Service Domains candidatos, leia a ficha do domínio com o padrão anotado, valide o nome contra a lista da versão fixada e escolha um dono humano por domínio. Sem dono, o mapa morre na primeira reorganização.

Depois vem o heatmap. Use quatro cores: manter, comprar, construir e aposentar. Manter é para o que funciona e não diferencia. Comprar é para commodity com fornecedor maduro. Construir é para onde o banco compete. Aposentar é para o que saiu do negócio ou está duplicado. Cada cor precisa de evidência: incidente, custo de manter ou roadmap. Sem evidência, é opinião pintada.

A lição dura aqui: BIAN não substitui julgamento arquitetural. Ele tira a conversa do achismo e obriga o time a mostrar o registro, o dono e a evidência.

> **Na prática:** Na prática, eu desconfio de qualquer mapa que não tenha dono humano, evidência por cor e versão explícita do landscape. O desenho pode estar bonito, mas a operação vai cobrar o que ficou implícito.

## As oito técnicas em quatro pares

Use o diagrama como roteiro de trabalho: primeiro nomeie capacidades, depois proteja registros, depois feche contratos, depois migre sem apostar tudo em uma virada.

### 🗺️ Mapa / Map

- 1. Capacidades sistemas reais (data)
- 2. Heatmap evidência por cor (data)

### 🔐 Fronteiras / Boundaries

- 3. Fronteira dono do registro (security)
- 4. Evento fato no passado (messaging)

### 📜 Contratos / Contracts

- 5. Contrato Semantic API cortada (edge)
- 6. Dono e leitor qualidade no dono (data)

### 🔧 Mudança / Change

- 7. Estranguladora cinco camadas (compute)
- 8. Fornecedor cinco perguntas (external)

### Fluxos

- decision -> cap: começa pelo que o sistema faz
- cap -> heat: vira critério de investimento
- heat -> boundary: mostra onde o registro muda de dono
- boundary -> event: publica fato só pelo dono
- event -> api: contrato usa nomes v14
- api -> dataowner: leitor não corrige cópia
- dataowner -> strangler: migração respeita escrita
- strangler -> vendor: compra com saída escrita

## Fronteira é onde muda o dono do registro

A terceira técnica é simples de dizer e difícil de sustentar: a fronteira passa onde muda o dono do registro. Um time pode cuidar de dois domínios. Dois times nunca escrevem no mesmo registro.

Isso parece detalhe organizacional, mas é arquitetura no nível mais concreto. Se dois sistemas corrigem o mesmo endereço, você não tem integração, tem disputa. A correção deve acontecer no dono do dado. No exemplo desta aula, endereço errado se corrige no `Party Reference Data Directory`. O leitor pode assinar evento, consultar API e guardar cópia de leitura. Ele não vira dono porque a tela dele encontrou o erro primeiro.

Eventos seguem a mesma disciplina. Eu uso um envelope com quatro itens: nome na forma `Domínio.Qualifier.FatoNoPassado`, dono, versão do landscape e chave de idempotência. `ConsumerLoan.Repayment.Executed` é um exemplo de forma: domínio e qualifier oficiais, fato no passado definido pelo autor. A versão pode aparecer como `BIAN 14.0.0`. A chave de idempotência existe porque o consumidor vai receber o mesmo evento mais de uma vez. O BIAN dá o vocabulário. O envelope é decisão minha.

### Técnicas

1. **Dois times precisam escrever no mesmo registro. O que isso indica?**
- [x] A fronteira está errada ou o dono não existe, _A fronteira passa onde muda o dono do registro._
- [ ] É normal com um lock distribuído, _Lock resolve concorrência, não propriedade do dado._
- [ ] Os dois times devem virar um só, _A saída é definir o dono, não fundir times._
- [ ] O BIAN exige um serviço por domínio, _Service Domain é fronteira candidata._

2. **Na migração estranguladora, qual é o erro mais comum?**
- [x] Pular da fachada direto para a escrita nova, _Eventos espelho e leitura nova vêm antes._
- [ ] Publicar eventos espelho cedo demais, _Eles são a segunda camada, de propósito._
- [ ] Começar pela fachada, _A fachada é a primeira camada._
- [ ] Desligar o legado no fim, _Desligar é a última camada._

## Contrato pequeno, migração sem salto mortal

A quinta técnica é contrato. Não copie a Semantic API inteira para dentro do seu banco. Parta do caminho da Semantic API, corte o que não usa, adicione autenticação, idempotência, erros e versionamento, e teste por script contra o YAML oficial. O `Current Account` tem 34 operações. Usar todas só para parecer aderente é trocar precisão por ruído.

A sexta técnica separa dono e leitor do dado. O dono escreve, publica e responde pela qualidade. O leitor assina ou consulta, guarda uma cópia de leitura quando precisa, e manda a correção para o dono. Isso reduz o blast radius de cada mudança porque a fonte de verdade não vira votação entre sistemas.

A sétima técnica é migração estranguladora em cinco camadas: fachada, eventos espelho com nomes v14, leitura nova, escrita nova e desligar. Pular da fachada direto para a escrita nova é onde migrações quebram. A fachada compra tempo, mas não compra consistência.

A oitava técnica é avaliar fornecedor com cinco perguntas por escrito: qual versão do landscape, quais Service Domains cobre e não cobre, quais eventos e APIs usam nomes v14, como os dados saem no fim, e quem paga a atualização de versão do BIAN.

## Rotina semanal para não deixar o mapa virar decoração

1. **Faça as três perguntas em toda decisão**: Quem é o dono do registro? Qual é o padrão funcional? Que fato esse dono publica para os vizinhos?

2. **Leia um domínio inteiro por semana**: Leia a ficha e o YAML. O ganho vem do detalhe, não do nome do domínio em uma planilha.

3. **Valide todo nome novo**: Todo Service Domain novo passa pela lista da versão fixada. `Payment Execution`, `Payment Order` e `Payment Instruction` são obsoletos na v14.

4. **Escreva uma ADR com fonte**: Uma decisão por semana basta, desde que cite a definição usada e a consequência operacional assumida.

## Seis realidades e o que fazer na segunda de manhã
| Realidade | Foco de segunda | Leitura arquitetural | Cuidado |
| --- | --- | --- | --- |
| Banco grande | Criar vocabulário comum entre dezenas de times e nomear dono por domínio. | Regras de porte importam. O LCR se aplica a ativo total acima de R$ 100 bilhões pela Resolução 4.401. | Sem dono por domínio, o mapa vira glossário sem operação. |
| Banco médio | Escolher onde construir e onde comprar commodity. | Modernização é roteiro plurianual, não mutirão de troca de sistemas. | Construir tudo consome a equipe antes de entregar diferenciação. |
| Fintech | Achar a primeira costura onde o dono já é outro. | O mapa não serve para desenhar trezentos microsserviços. Uma sociedade de crédito direto é instituição financeira pela Resolução CMN 5.050/2022, art. 3º. | Granularidade demais cria operação demais. |
| Cooperativa de crédito | Perguntar se o domínio é da singular ou do sistema. | Pela Lei Complementar 130/2009, há serviços financeiros aos associados por mutualidade. Minha leitura: a parte é associado, a elegibilidade confere a associação, e alguns domínios podem ser compartilhados na central. | Captação e crédito têm restrições aos associados, com ressalvas. Não trate como banco comercial genérico. |
| Instituição de pagamento | Separar modalidade antes de mapear domínio. | A Lei 12.865/2013, art. 6º, § 2º, veda atividades privativas de instituição financeira. O art. 12 trata recursos em conta de pagamento como patrimônio separado. | Pela Resolução BCB 80/2021, o iniciador de transação de pagamento não gerencia conta nem detém fundos. |
| Consultoria e fornecedor | Escrever escopo em Service Domains com versão. | Aceite deve falar em operações e eventos, não em módulo comercial. | Sem cláusula de saída de dados e atualização de versão, o custo aparece no próximo ciclo. |

## As seis realidades mudam o uso do mapa

O mesmo BIAN não produz a mesma agenda em toda instituição. Em banco grande, ele reduz tradução entre dezenas de times e força dono por domínio. Em banco médio, ele ajuda a escolher o que construir e o que comprar, porque a equipe não aguenta modernizar tudo ao mesmo tempo.

Em fintech, o mapa não é desculpa para quebrar tudo em microsserviços. Ele mostra a primeira costura onde o dono já é outro. Em cooperativa de crédito, a pergunta operacional é diferente: isto pertence à singular ou ao sistema? Pela Lei Complementar 130/2009, serviços financeiros são prestados aos associados por mutualidade. Minha leitura é tratar a parte como associado, a elegibilidade como conferência de associação, e domínios compartilhados como assunto da central quando o sistema opera junto.

Em instituição de pagamento, a modalidade muda o mapa. Minha leitura: emissor de moeda eletrônica fica perto de um domínio Fulfill de conta; pós-pago fica perto de `Credit Card`; credenciador vai para `Merchant Acquiring Facility`; iniciador vai para `Payment Order Initiation`. Isso é leitura do autor, não fato do BIAN nem da norma.

Para consultoria e fornecedor, escopo bom tem versão, Service Domains, operações, eventos e saída de dados. O resto é conversa que vira aditivo.

## O que você deve levar para o trabalho

- BIAN 14 é vocabulário operacional. Use nomes atuais: `Payment Order Initiation`, `Payment Rail`, `Card Transaction Tracking`, `Payee Management`, `Payment Orchestration`, `Payment Confirmation`, `Payment Settlement` e `Customer Consent` quando couber.
- Fronteira boa segue o dono do registro. Organograma ajuda, mas não decide escrita.
- Contrato bom é menor que a Semantic API completa e mais explícito sobre autenticação, idempotência, erro e versão.
- Fornecedor bom responde por escrito o que cobre, o que não cobre, como integra, como sai e quem paga a evolução do BIAN.

### Modalidades da Resolução BCB 80 no mapa (mapeamento do autor)

- **Emissor de moeda eletrônica**: Gerencia conta de pagamento pré-paga. Ponto de partida: um domínio Fulfill de conta.
- **Emissor de instrumento pós-pago**: Emite instrumento de pagamento pós-pago. Ponto de partida: perto do Credit Card.
- **Credenciador**: Habilita quem recebe pagamentos. Ponto de partida: Merchant Acquiring Facility.
- **Iniciador de transação de pagamento**: Inicia o pagamento sem gerenciar conta nem deter os fundos. Ponto de partida: Payment Order Initiation.

## Perguntas que aparecem quando o mapa encontra a operação

### Posso ter dois domínios no mesmo time?

Sim. O problema não é um time cuidar de dois domínios. O problema é dois times escreverem no mesmo registro.

### Preciso implementar toda Semantic API?

Não. Parta do caminho oficial, corte o que não usa e adicione os controles que operação cobra: autenticação, idempotência, erros e versionamento.

### O mapeamento das modalidades da Resolução BCB 80 é oficial do BIAN?

Não. Nesta aula, esse mapeamento é leitura do autor. Ele serve para raciocinar com precisão, não para fingir que a norma publicou um Service Domain.

## Veredito

Use o BIAN na segunda de manhã quando ele amarrar decisão a domínio, registro, contrato e evidência. Se ele virar só catálogo de nomes, pare e volte para a pergunta operacional: quem escreve, quem lê, quem publica, quem paga a mudança e quem responde quando falha.

### 17. Dois casos fictícios e IA Builder no banco inteiro

_As decisões do Banco Ipê e da Trilha, e um laço de IA que não traz nome velho para o desenho._

A última aula da parte 2 junta o banco por dentro em dois casos fictícios e um laço de IA. O ponto não é decorar o mapa, é aprender a usá-lo sem trazer nome obsoleto, fronteira errada ou política escondida no código para dentro do desenho.

## Dois casos, nenhum banco real

Os casos do Banco Ipê e da Trilha são fictícios, montados só com material público e com o mapa do BIAN 14.0 como referência funcional. Nenhum dos dois descreve a arquitetura interna de um banco real. Isso importa porque o exercício aqui é técnico: separar registro, decisão, contrato, evento e responsabilidade operacional.

No Banco Ipê, o problema é comum: a política de crédito está escrita dentro da esteira. Mudar um corte de score exige versão nova do sistema. O core de empréstimos funciona e fica. O objetivo é mudar a política sem tocar no contrato nem no core.

Na Trilha, a dor é outra. Cinco módulos vivem no mesmo código e no mesmo banco: cadastro, conta pré-paga, Pix, antifraude e financeiro. O mapa mostra dezessete domínios, mas isso não significa criar dezessete microsserviços. Significa enxergar as costuras antes de escolher a ordem do corte.

A lição de fechamento é simples: BIAN não decide por você. Ele reduz ambiguidade. A decisão continua sendo sua, com risco, sequência e custo de operação na mesa.

> **Minha leitura:** Na prática, antes de trocar um sistema, eu procuro o registro que muda mais rápido que ele. No Ipê, não era o contrato do empréstimo. Era a política de crédito. Trocar o core inteiro resolveria o problema errado.

## Banco Ipê: tirar a política de dentro da esteira

O heatmap do Ipê preserva o que não precisa mudar: Session Dialogue, Party Lifecycle Management, Credit Risk Models, Customer Credit Rating, Consumer Loan e Disbursement. Compra o que não diferencia: Document Services, Correspondence e Collateral Asset Administration. Constrói onde a política e a experiência importam: Customer Offer e Underwriting. A esteira legada é aposentada no fim, não no começo.

O fluxo alvo fica mais legível. Customer Offer orquestra e guarda só o estado da oferta. Customer Credit Rating, no padrão Monitor, responde o score com versão do modelo. Underwriting decide com política versionada fora do código. Consumer Loan, no padrão Fulfill, cria o contrato no core por um adaptador. Disbursement, no padrão Transact, libera de forma idempotente. Financial Accounting, no padrão Track, lança.

O caminho oficial v14 usado no caso é `POST /Underwriting/Evaluate`. O cabeçalho `Idempotency-Key` e o campo `PolicyVersion` são do caso, não do BIAN. Essa distinção evita um erro silencioso: tratar uma convenção local como se fosse semântica oficial.

A migração segue cinco fases: fachada no pedido, eventos espelho, decisão em sombra, novo decide quando a divergência está explicada, esteira desligada. Sombra aqui quer dizer decidir em paralelo sem efeito no cliente, para comparar decisão antiga e nova antes de trocar o dono da resposta.

## ADR do Banco Ipê

### Trocar o core inteiro

**Pros**
- Removeria limitações antigas em uma única iniciativa.

**Cons**
- Resolveria o problema errado, porque o core de empréstimos funciona.
- A política continuaria podendo nascer acoplada a outro sistema.

**Verdict:** Descartado.

### Separar oferta e decisão

**Pros**
- Permite mudar política sem release do core.
- Mantém o contrato no sistema que já cumpre esse papel.

**Cons**
- Aumenta o custo de operar eventos e comparar decisões em sombra.

**Verdict:** Escolha recomendada no caso.

### Os casos

1. **No Banco Ipê (fictício), por que não trocar o core de empréstimos?**
- [x] Porque o que mudava toda semana era a política de crédito, presa no lugar errado, _Ache o registro que muda mais rápido que o sistema._
- [ ] Porque o BIAN proíbe trocar o core, _O BIAN não decide portfólio._
- [ ] Porque o core é Transact, _Consumer Loan é Fulfill, e o padrão não é o motivo._
- [ ] Porque o Underwriting fica dentro do core, _O Underwriting virou serviço próprio no caso._

2. **A checagem de grounding do Bedrock Guardrails pega qual destes erros?**
- [x] Justificativa que não está na fonte recuperada, _Ela mede grounding e relevância._
- [ ] Nome certo de uma versão errada indexada, _Se a fonte é a errada, a resposta parece apoiada._
- [ ] Escopo de norma brasileira, _Isso fica com o validador e o humano._
- [ ] A decisão de arquitetura, _A decisão tem dono humano._

## Trilha: dezessete domínios, quatro cortes

A Trilha tem um monólito com cadastro, conta pré-paga, Pix, antifraude e financeiro no mesmo código e banco. O mapeamento em v14 fica assim: cadastro usa Party Reference Data Directory, Party Lifecycle Management e Party Authentication. Conta usa Current Account, Position Keeping e Issued Device Administration. Pix usa Payment Order Initiation, Payee Management, Payment Orchestration, Payment Confirmation, Payment Rail e Payment Settlement. Antifraude usa Fraud Evaluation, Fraud Diagnosis e Fraud Resolution. Financeiro usa Financial Accounting e Regulatory Reporting.

A ordem do corte não vem do número de domínios. Vem do risco. Primeiro cadastro, porque todos escrevem nele. Depois antifraude, porque tem dono e ritmo próprios. Depois financeiro, porque recebe eventos sem tocar no fluxo do cliente. Pix fica por último, porque é fluxo de 24 horas e tolera menos experimento.

Antes de cada corte, entram eventos espelho com nomes claros: `PartyReferenceDataDirectory.Reference.Updated`, `CurrentAccount.AmountBlock.Initiated`, `CurrentAccount.DebitandCredit.Executed`, `PaymentOrderInitiation.OrderInitiation.Initiated` e `FraudEvaluation.Models.Evaluated`. Essa forma é minha, usando domínios e qualifiers oficiais para dar disciplina ao contrato.

A Lei 12.865/2013, art. 12, muda o desenho: recursos em conta de pagamento são patrimônio separado. Para a arquitetura, o saldo do cliente tem um dono só e nenhum serviço novo mantém saldo paralelo.

## Erros que a Trilha evita

- **Um microsserviço por domínio:** o mapa não é organograma de deploy.
- **Cortar Pix primeiro:** o fluxo de 24 horas é o pior lugar para aprender a estrangular o monólito.
- **Saldo duplicado:** a conta de pagamento exige um dono claro para o saldo, não cópias otimistas em serviços novos.
- **Confundir costura com sequência:** dezessete domínios mostram as costuras, mas a ordem vem do risco.

## Laço de IA Builder, do pedido ao ADR

O agente ajuda a mapear, mas o validador e o arquiteto impedem que nome obsoleto ou fonte errada vire desenho oficial.

### 👤 Arquitetura: pedido e decisão

- Pedido do arquiteto parte do banco ou produto local (user)
- ADR mapeamento decidido (data)

### 🤖 IA: proposta com grounding

- Agente IA Builder propõe domínio e padrão (ai)
- Fichas BIAN v14 versão fixada (data)
- Contextual grounding check fonte pergunta conteúdo (security)

### 🔐 Controle: lista fechada

- Validador em código rejeita obsoleto e inventado (security)
- Arquiteto aceita ajusta ou recusa (user)

### Fluxos

- request -> agent: pede mapeamento
- agent -> index: busca fichas v14
- agent -> validator: envia domínio padrão e trecho
- validator -> grounding: checa apoio na fonte
- grounding -> human: mostra grounding e relevância
- human -> adr: decide e registra
- validator -> agent: devolve substituto quando existe

## IA Builder no banco inteiro

O laço de IA Builder fecha o curso porque ele força uma disciplina: a IA rascunha, o código valida, o arquiteto decide. O arquiteto pede o mapeamento. O agente busca nas fichas v14 indexadas com versão fixada. Ele propõe domínio, padrão e trecho da ficha. O validador usa lista fechada: fora da lista rejeita; obsoleto rejeita e devolve o substituto anunciado quando existe, como Payment Order para Payment Confirmation; novo sem status passa marcado como novo. Depois vem checagem de grounding, e a decisão entra no ADR.

Amazon Bedrock Guardrails, no contextual grounding check, mede duas coisas: grounding, se a resposta está apoiada na fonte, e relevância, se responde à pergunta. O limiar é configurável de 0 a 0,99. Ele precisa de fonte, pergunta e conteúdo. Pega justificativa inventada, mas não pega nome certo de versão errada se a fonte indexada for a errada. Também não decide escopo de norma.

Os modos de falha da parte 2 são práticos: cenário oficial com linha de vida obsoleta, falso amigo como Suitability Checking, nomes parecidos com status diferentes como Direct Debit e Direct Debit Collection, domínio inventado para conceito local como KYC, boleto ou conta-salário.

LGPD art. 20 trata revisão de decisão automatizada, inclusive perfil de crédito. Circular 3.978 art. 44 lembra que análise de lavagem não se terceiriza. A IA apoia o analista, com trilha. Ela não substitui responsabilidade.

### A migração estranguladora

Ordene as cinco camadas, da primeira à última.

1. Fachada: toda chamada passa por uma porta nova
2. Eventos espelho: o legado publica fatos com nomes v14
3. Leitura nova: consultas saem do domínio novo
4. Escrita nova: o domínio novo vira dono do registro
5. Desligar: o legado perde a última função

## Como medir o laço

- **v14**: Versão fixada. A avaliação só vale se a fonte indexada estiver congelada na mesma versão.
- **0 a 0,99**: Limiar configurável. Use no contextual grounding check para grounding e relevância.
- **4**: Sinais acompanhados. Precisão por domínio, taxa de nomes rejeitados, concordância com o arquiteto e reexecução a cada troca de modelo ou versão.

## Cinco passos para a próxima semana

1. **Fixe a versão**: Escolha BIAN 14.0 e impeça que o repositório misture nomes de versões diferentes.

2. **Aplique as três perguntas**: Escolha uma parte do banco e faça as três perguntas: quem é o dono do registro, qual é o padrão funcional e que fato ele publica.

3. **Mapeie um produto local pelo comportamento**: Use o que o produto faz, não o nome local. KYC, boleto e conta-salário não viram domínio por vontade do projeto.

4. **Confira um cenário nome por nome**: Pegue a linha de vida oficial e valide cada nome contra a lista v14 antes de desenhar setas.

5. **Registre o primeiro desvio**: Quando o mapa não encaixar, escreva um ADR. O valor está em explicar a exceção, não em fingir aderência.

### Recapitulação da parte 2

- **Módulo 4**: Um banco por dentro: cadastro, pagamentos de varejo, cartão, crédito, cobrança, investimentos, fraude e lavagem de dinheiro.
- **Módulo 5**: No trabalho: bastidores, cliente 360, oito técnicas, seis realidades, dois casos fictícios e IA no banco inteiro.
- **Em uma frase**: O BIAN não desenha o seu banco: ele dá nome às partes para você decidir onde ficam as paredes.

## Fechamento

### O que a parte 2 deveria mudar no meu trabalho?

Você deve sair menos impressionado com nomes de sistemas e mais atento a registros, padrões, eventos, responsabilidades e normas que limitam a decisão.

### Quando usar IA nesse processo?

Use IA para rascunhar mapeamentos e contratos com fonte fixada, lista fechada, grounding e revisão humana. Sem isso, ela só acelera erro com vocabulário bonito.

### Qual é o próximo passo no curso?

Siga para a parte 3, o crédito por dentro: o documentário e as aulas 18 a 24 do módulo 6 levam o mesmo método para as linhas de crédito, a decisão, os limites, as garantias e a cobrança. O exame final e o certificado ficam na página do curso; o certificado deve provar que você sabe usar o mapa com decisão, não que decorou uma lista de domínios.

## Módulo 6: O crédito por dentro

As linhas de varejo, da proposta à decisão, rating e perda esperada, limites e a árvore de crédito, garantias e contrato, carteira e cobrança, regulação, o core de crédito e IA no crédito.

### 18. As linhas de crédito do varejo e o mapa

_Cartão, cheque especial, consignado, veículo, imobiliário, giro e recebíveis: o que muda entre eles e onde cada um fica na v14._

Depois do documentário O crédito por dentro, a pergunta muda. Não é mais onde o banco guarda a conta, é como cada linha de crédito muda prazo, garantia, risco, preço e regra. Nesta aula, Marina, Rafael, o Café Aurora Centro, a Rede Aurora e a Torra Boa são fictícios, com números apenas para fixar o mapa.

## Comece pelo comportamento, não pelo nome comercial

Marina tem 34 anos, trabalha como analista CLT, recebe salário bruto de R$ 7.500, usa cartão com limite de R$ 12 mil e tem cheque especial de R$ 2 mil. Ela pede um consignado privado de R$ 20 mil em 36 parcelas, financia um carro de R$ 75 mil com entrada de R$ 30 mil e R$ 45 mil financiados em 48 parcelas com alienação fiduciária, e depois compra um apartamento de R$ 400 mil financiando R$ 300 mil.

Rafael, dono do Café Aurora Centro, microempresa e franquia da Rede Aurora, precisa de capital de giro e antecipação de recebíveis de cartão. O erro comum seria procurar no BIAN por nomes comerciais brasileiros. Na segunda de manhã, eu faço o inverso: pergunto se a linha é rotativa ou parcelada, se tem bem em garantia, se a parcela sai da folha, se o recebível foi vendido ou dado em garantia, e quem recebe o dinheiro no desembolso.

A lição dura por trás disso: produto local sem Service Domain próprio não vira improviso no mapa. Ele vira composição explícita, registrada em ADR, com o domínio v14 que executa a obrigação principal e os domínios ao redor que explicam regra, garantia, consentimento, pagamento e evidência.

> **Minha leitura de arquiteto:** Na prática, eu não começo perguntando se o produto chama consignado, cheque especial ou antecipação. Eu começo perguntando qual obrigação nasce, qual ativo ou fluxo segura essa obrigação, qual regra limita a cobrança, e onde o Control Record precisa deixar rastreabilidade.

## Linhas de varejo e leitura no mapa v14
| Linha | Comportamento | Lugar no mapa v14 | Ponto de atenção |
| --- | --- | --- | --- |
| Cartão | Limite, compras, fatura, rotativo e parcelamento | Credit Card, 28 operações, BQs Billing, CardPayment, Charge, CreditPlan, Interest, IssuedDevice e Repayment | `LimitSettings`, `LimitValue` e `LimitType` ficam no Control Record. Cartão de débito não entra nesse domínio. |
| Cheque especial | Crédito rotativo vinculado à conta corrente | Não existe Service Domain v14 de cheque especial. Aparece em Current Account por atributos como `OverdraftArrangement`, `OverdraftFeature`, `OverdraftService` e `Daylightoverdraft`, e como uso típico de Credit Facility. | Não invente BQ de cheque especial. |
| Consignado privado | Empréstimo parcelado com repagamento por desconto em folha | Leitura do autor: Consumer Loan, 29 operações, com Corporate Payroll Services ao lado do empregador conveniado | A margem da Marina não é calculada aqui: a base de cálculo é a que a lei define, e ela fica fora desta aula. |
| Veículo | Financiamento de bem maior, com o item administrado como garantia | Merchandising Loan, 47 operações, BQ CollateralAllocation | No cenário oficial `EXT Disburse Merchandising Loan`, view 55527, o passo é `Confirm Payment Order to Merchant`, então o dinheiro vai para a loja. O cenário ainda cita Payment Order, nome obsoleto na v14. |
| Imobiliário | Financiamento com título da propriedade normalmente administrado como garantia | Mortgage Loan, 47 operações | O mapa separa o contrato de crédito da evidência de garantia. |
| Capital de giro e recebíveis | Crédito empresarial ou liquidez curta por recebíveis | Corporate Loan, 29 operações, para capital de giro. Factoring, 36 operações, para compra de contas a receber com desconto. | Pela Res. 4.734/2019, art. 2º, desconto é cessão definitiva no inciso V, com cara de Factoring. Operação de crédito garantida por recebíveis é outra coisa no inciso VI, leitura do autor: Corporate Loan com garantia registrada. |

## Mapa mental das linhas por garantia

A mesma palavra crédito esconde obrigações bem diferentes. O agrupamento por garantia evita mapear produto pelo apelido comercial.

### 👤 Cliente: pessoa física

- Marina perfil fictício (user)

### 🔓 Sem garantia real

- Credit Card limite e fatura (data)
- Current Account plus Credit Facility cheque especial (data)
- Consumer Loan pessoal e consignado (data)

### 🏠 Bem em garantia

- Merchandising Loan veículo (data)
- Mortgage Loan imóvel (data)
- Leasing bem arrendado (data)

### 💳 Recebíveis

- Café Aurora Centro perfil fictício (user)
- Corporate Loan capital de giro (data)
- Factoring compra de recebíveis (data)

### Fluxos

- marina -> card: limite de cartão
- marina -> overdraft: conta com limite rotativo
- marina -> consumer: empréstimo pessoal ou consignado
- marina -> vehicle: carro financiado, pagamento à loja
- marina -> mortgage: imóvel como garantia
- rafael -> corp: capital de giro
- rafael -> factoring: cessão definitiva de recebíveis

## O que muda de verdade entre as linhas

A pergunta da aula tem cinco respostas: prazo, garantia, risco, preço e regra. Cartão e cheque especial parecem próximos porque são rotativos, mas vivem em lugares diferentes no mapa. Credit Card trata cartão de crédito e charge card, com fatura, juros, pagamento, plano de crédito e limite. Cheque especial não tem domínio próprio em v14; ele aparece como limite rotativo vinculado à conta corrente e como caso típico de Credit Facility.

Consumer Loan é o lugar natural para empréstimo pessoal e, na minha leitura, para consignado privado quando a obrigação é um empréstimo ao consumidor com repagamento por desconto em folha. O domínio não vira consignado só porque o Brasil chama assim. A composição precisa mostrar o empregador conveniado, e Corporate Payroll Services explica o lado da folha.

Merchandising Loan muda a conversa porque o bem comprado tende a ser administrado como garantia. No cenário oficial de desembolso, o passo `Confirm Payment Order to Merchant` deixa uma pista operacional importante: no carro da Marina, o dinheiro não precisa passar pela mão dela. Mortgage Loan segue lógica parecida com imóvel, mas com título da propriedade como garantia. Leasing é outro desenho: o banco mantém interesse de garantia no bem arrendado.

### A linha e o lugar no mapa v14

- **Cartão de crédito da Marina** → Credit Card
- **Cheque especial** → Limite no Current Account (sem domínio próprio)
- **Consignado privado** → Consumer Loan com desconto em folha (mapeamento do autor)
- **Carro financiado** → Merchandising Loan
- **Apartamento** → Mortgage Loan
- **Capital de giro do Café Aurora** → Corporate Loan
- **Desconto de recebíveis (cessão definitiva)** → Factoring

## Regras que você precisa carregar no mapa

- Cartão, Res. 4.549/2017: saldo não pago só pode ir ao rotativo até o vencimento da fatura seguinte, depois deve virar parcelamento em condições mais vantajosas, e o que foi parcelado não volta ao rotativo.
- Lei 14.690/2023, art. 28, com Res. CMN 5.112/2023: juros e encargos do rotativo e do parcelamento da fatura não podem exceder o valor original da dívida, com renegociação assegurada a qualquer momento com esse teto.
- Cheque especial, Res. 4.765/2019: para pessoa natural e MEI, é concessão de limite de crédito rotativo vinculado a conta de depósitos à vista, com juros limitados a 8% ao mês.
- Consignado CLT, Lei 10.820/2003 com redação da Lei 14.431/2022: até 40%, sendo 35% para empréstimos, financiamentos e arrendamentos, e 5% exclusivamente para cartão de crédito consignado. A Lei 15.179/2025 incluiu operações em plataformas digitais mantidas por agentes operadores públicos, sem tirar os canais das instituições.
- INSS, Lei 8.213/1991, art. 115, VI: até 45%, sendo 35% para empréstimos, 5% para cartão consignado e 5% para cartão consignado de benefício.

## Recebíveis não são uma coisa só

O caso do Rafael é onde muita arquitetura derrapa. Capital de giro para o Café Aurora Centro fica naturalmente em Corporate Loan, porque a obrigação principal é crédito empresarial. Antecipação de recebíveis de cartão exige mais cuidado, porque a Res. 4.734/2019 separa duas figuras no art. 2º.

Quando há desconto, o inciso V fala em cessão definitiva de recebíveis. Minha leitura para o mapa é Factoring, porque a ficha do domínio fala em comprar contas a receber do cliente com desconto para gerar liquidez de curto prazo. As BQs FactoringEvaluation, FactoringPurchase, FactoringProcessing e AccountReceivableFactoring deixam claro que o recebível não é só um campo em contrato de crédito.

Quando há operação de crédito garantida por recebíveis, o inciso VI descreve outra coisa. Minha leitura, caso a caso, é Corporate Loan com a garantia registrada. Parece detalhe de modelagem, mas muda cobrança, risco, baixa contábil, conciliação e evidência para auditoria. Se você tratar tudo como antecipação em um único produto genérico, o mapa fica bonito na apresentação e fraco no incidente.

## Como mapear na segunda de manhã

1. **Descreva o comportamento**: Escreva se a linha é rotativa ou parcelada, se o pagamento vem do cliente, da folha, do lojista, do empregador ou de um fluxo de recebíveis.

2. **Localize a obrigação principal**: Use Credit Card, Consumer Loan, Merchandising Loan, Mortgage Loan, Corporate Loan, Leasing, Factoring ou Loan conforme a obrigação que o domínio cumpre.

3. **Registre a composição**: Quando o produto local não existir como Service Domain, escreva o ADR. Cheque especial e consignado precisam disso para não virarem domínio inventado.

4. **Prenda a regra ao contrato certo**: Cartão, cheque especial, consignado e recebíveis têm regras diferentes. A arquitetura precisa mostrar onde cada limite é aplicado e auditado.

## Perguntas que aparecem em revisão de arquitetura

### Posso criar um domínio Cheque Especial?

Não para dizer que é BIAN v14. O autor procurou nos 346 nomes e não há Service Domain v14 de cheque especial. Modele como composição com Current Account e Credit Facility, e documente a decisão.

### Consignado é Consumer Loan ou um domínio próprio?

Na minha leitura, Consumer Loan com repagamento por desconto em folha, mais Corporate Payroll Services do lado do empregador conveniado. Não existe Service Domain v14 de consignado.

### Loan genérico resolve tudo?

Loan existe e tem 24 operações, mas usar genérico cedo demais apaga a razão operacional da linha. Se há cartão, veículo, imóvel, empresa, leasing ou factoring, comece pelo domínio específico.

### Checagem rápida

1. **A Marina não pagou a fatura inteira. Pela Res. 4.549, até quando o saldo pode ficar no rotativo?**
- [x] Até o vencimento da fatura seguinte; depois, só parcelamento em condições mais vantajosas, _E o que foi parcelado não volta ao rotativo._
- [ ] Por até 12 meses, _A regra é até o vencimento da fatura seguinte._
- [ ] Sem prazo, enquanto pagar o mínimo, _O rotativo tem prazo definido na norma._
- [ ] A regra vale igual para o cartão consignado, _O art. 4º exclui o cartão consignado._

2. **Quem recebe o dinheiro no desembolso oficial de Merchandising Loan da v14?**
- [x] A loja que vendeu o bem, _O passo é 'Confirm Payment Order to Merchant'._
- [ ] A cliente, na conta corrente, _No crédito para comprar um bem, quem recebe é a loja._
- [ ] A franqueadora, _Não há franqueadora nesse cenário._
- [ ] O Banco Central, _O BC não participa do desembolso._

## Veredito

A forma certa de abrir crédito no BIAN 14 não é decorar nomes de produtos, é separar comportamento, garantia e regra. Cartão vai para Credit Card. Carro vai para Merchandising Loan. Imóvel vai para Mortgage Loan. Capital de giro vai para Corporate Loan. Cessão definitiva de recebíveis, na minha leitura, vai para Factoring. Cheque especial e consignado exigem composição documentada, porque inventar domínio é dívida arquitetural com nome bonito.

**Rating:** recommended

### 19. Da proposta à decisão: originação, SCR e Cadastro Positivo

_O pedido de consignado da Marina e o de giro do Café Aurora, do primeiro clique à decisão, com quem decide e quem só consulta._

Marina pede um consignado privado de R$ 20 mil em 36 parcelas. Rafael pede capital de giro para o Café Aurora Centro. A pergunta perigosa não é se a tela aceita a proposta, é quem decide crédito, quem só consulta dado e qual registro prova que a consulta podia acontecer.

## A proposta não nasce como dívida

Na originação, o primeiro erro é tratar o clique da Marina como um contrato. Ele ainda é uma intenção. O banco precisa entender o produto, a elegibilidade, a relação do cliente, a capacidade de pagamento, a política de crédito e a contabilidade que será afetada se a operação for aprovada.

Os quatro cenários oficiais de originação de empréstimo pessoal no BIAN 14.0 ajudam a separar essas responsabilidades. Em `Handle Request for Consumer Loan Checks and Options`, aparecem Party Reference Data Directory, Customer Offer, Product Directory, Lead and Opportunity Management, Customer Agreement, Customer Product And Service Eligibility, Session Dialogue e Party Lifecycle Management. As mensagens incluem `Verify Product Eligibility` e `Retrieve Customer Master Agreement`.

Depois vem `Handle Request for Consumer Loan Configuration and Pricing`, com Consumer Loan, Customer Offer, Session Dialogue, Customer Credit Rating e Product Directory. Aqui entram `Get customer credit assessment` e `Get Product Pricing and Options`.

Na leitura do autor, essa sequência ensina algo simples: Customer Offer orquestra a conversa comercial, mas não vira juiz de crédito. Quem confunde orquestração com decisão coloca regra crítica no lugar errado e depois não consegue explicar a negativa, a taxa ou a exigência de garantia.

> **Na prática:** Eu desenho originação de crédito começando pela fronteira de decisão. Se Underwriting decide, ele precisa receber evidência, política e rating com versão. Ele não precisa guardar todos os dados consultados. Essa separação reduz auditoria artesanal quando alguém pergunta por que Marina foi aprovada ou por que Rafael recebeu uma condição diferente.

## Originação com Underwriting no centro

O desenho separa conversa comercial, dados consultados, decisão de crédito e visão agregada do banco.

### 👤 Cliente: Entrada

- Session Dialogue Coleta intenção (frontend)
- Customer Offer Orquestra oferta (compute)

### 📦 Produto: Elegibilidade

- Customer Product And Service Eligibility EligibilityCheck (compute)
- Product Matching Produtos elegíveis (compute)
- Product Directory Preço e opções (data)

### 🔍 Dados: Evidência

- Customer Credit Rating Rating interno e externo (data)
- Information Provider Operation Feeds comerciais (external)
- Financial Statement Assessment Balanço do Café Aurora (data)

### ⚖ Crédito: Decisão

- Underwriting Determinação condicional (security)
- Credit Management Visão de crédito do banco (compute)
- Financial Accounting Update GL Accounts (data)

### Fluxos

- marina -> session: inicia proposta
- rafael -> session: inicia proposta
- session -> offer: contexto da oferta
- offer -> eligibility: verifica elegibilidade
- eligibility -> matching: isola produtos possíveis
- offer -> product: busca preço e opções
- underwriting -> rating: consulta rating
- rating -> provider: relatórios externos
- underwriting -> statements: usa balanço no Café Aurora
- offer -> underwriting: pede decisão
- underwriting -> creditmgmt: adiciona à visão de crédito
- creditmgmt -> ledger: fecha contabilização

## SCR e Cadastro Positivo entram como evidência, não como atalho

O SCR, pela Res. CMN 5.037/2022, tem finalidades de supervisão e intercâmbio entre instituições, conforme o art. 2º. O art. 3º inclui operações como empréstimos, financiamentos, arrendamento, aval e fiança, créditos a liberar, créditos baixados como prejuízo e cartão, independentemente do adimplemento. Sociedade de crédito direto também reporta, pelo art. 4º, XX.

O titular acessa seus dados pelo art. 8º. Na prática do cidadão, a consulta acontece pelo Registrato, com conta gov.br nível prata ou ouro e verificação em duas etapas. A instituição só consulta com autorização específica do cliente, art. 12, e deve haver comunicação prévia, art. 13. Atraso igual ou superior a sessenta meses fica fora do intercâmbio, art. 14. A página do BCB informa registro a partir de R$ 200,00 de risco e alimentação mensal.

Cadastro Positivo segue outra lógica. Pela Lei 12.414/2011, com a LC 166/2019, o gestor está autorizado a abrir o cadastro, com inclusão automática e direito de saída, e disponibilizar a nota de crédito. O cadastrado deve ser comunicado em até 30 dias com canais de cancelamento. O art. 5º garante cancelamento ou reabertura, acesso gratuito ao histórico e à nota, correção em até 10 dias, conhecimento dos principais elementos e critérios da análise, e revisão de decisão realizada exclusivamente por meios automatizados.

## A jornada do consignado da Marina

1. **1. Intenção e sessão**: Marina informa que quer um consignado privado de R$ 20 mil em 36 parcelas. Session Dialogue segura a conversa. Customer Offer organiza a oferta, sem decidir crédito.

2. **2. Produto e elegibilidade**: Customer Product And Service Eligibility avalia a elegibilidade, usando `POST /CustomerProductAndServiceEligibility/{id}/EligibilityCheck/Evaluate`. Quando precisa achar produtos adicionais, chama Product Matching.

3. **3. Acordo e autorização**: A consulta ao SCR exige autorização específica. No mapa, isso é registro auditável com data e finalidade, leitura do autor, não fato textual do BIAN nem da norma.

4. **4. Rating e decisão**: Customer Credit Rating pode integrar dados externos de agências de crédito com dados transacionais internos. Underwriting considera capacidade de pagamento e credit worthiness, e pode levar risco para taxa ou garantia.

5. **5. Fechamento**: No cenário `Handle Request for Consumer Loan Complete Origination`, Credit Management recebe `Add Asset to Credit View` e Financial Accounting executa `Update GL Accounts`. A dívida nasce quando a decisão e o fechamento existem, não no primeiro clique.

### O consignado da Marina, da proposta ao contrato

Ordene os passos (a ordem é do autor; o cenário oficial lista as linhas de vida).

1. Customer Offer abre a proposta
2. Customer Product And Service Eligibility confere a elegibilidade
3. Information Provider Operation traz os dados externos autorizados
4. Customer Credit Rating atualiza o rating
5. Underwriting decide
6. Credit Management põe a operação na visão de crédito do banco
7. Consumer Loan registra o contrato

## Underwriting decide, os vizinhos fornecem evidência

Underwriting, no BIAN 14.0, considera a capacidade do tomador de financiar o empréstimo com base nos fluxos de caixa conhecidos e na credit worthiness. A operação pode ser condicional. A ficha fala em `Make (conditional if needed) underwriting determination`, e as APIs incluem `POST /Underwriting/Evaluate` e `PUT /Underwriting/{underwritingid}/Grant`.

Customer Credit Rating é um domínio Monitor com 12 operações. Ele pode integrar dados externos de agências de crédito com dados transacionais internos, e sua ficha destaca `Access external rating agencies for customer credit reports`. Information Provider Operation opera a interface para importar feeds de provedores comerciais. Esses domínios não deveriam virar decisão escondida.

Para o Café Aurora Centro, entra Financial Statement Assessment. Ele é um domínio Assess com 26 operações e BQs como AssetandLiabilityValuationTest, LiquidityandCashFlowTest, RiskTest e SensitivityTest. No cenário `Review Borrower Financial Statements`, view 55768, aparecem `Assess Financial Statement` e `Update Customer Credit Rating`.

Credit Management fecha outro nível. Ele mantém a perspectiva de crédito do banco inteiro, avalia o encaixe de uma proposta nas políticas e prioridades de crédito e reprecifica grandes operações. A ficha usa `central bank` no sentido de função central do banco, não Banco Central. Credit and Margin Management define políticas de crédito e margem, mas aqui não há API citada.

## O que precisa ficar explícito no desenho

- Customer Offer orquestra a oferta. Underwriting decide crédito. Credit Management enxerga a proposta dentro da carteira e das prioridades de crédito do banco.
- A autorização do SCR não é detalhe de tela. Na leitura do autor, ela precisa virar evidência auditável com data e finalidade.
- Cadastro Positivo não elimina explicabilidade. O cliente tem direito de conhecer os principais elementos e critérios da análise e pedir revisão de decisão exclusivamente automatizada.
- O CDC, no art. 54-D, II, exige avaliação responsável das condições de crédito antes da contratação. Isso muda o desenho: decisão sem trilha é passivo operacional.

## Três erros que eu procuro cedo

O primeiro erro é Customer Offer decidir crédito. Parece prático porque a oferta está perto da tela, do preço e da campanha. Mas a proximidade com o cliente não dá autoridade de risco. Customer Offer pode incluir checagem de documentos, alocação de garantia, avaliação de crédito e decisão de underwriting na sua orquestração, mas isso não transforma orquestrador em dono da decisão.

O segundo erro é aprovar ou negar sem versão do modelo e da política. Score de aplicação, score de comportamento e safra são práticas de mercado, não definições normativas aqui. Mesmo assim, quando aparecem no desenho, precisam ter versão, motivo e evidência. Sem isso, a discussão vira opinião depois do incidente.

O terceiro erro é consultar SCR sem autorização registrada. A norma exige autorização específica do cliente para a consulta pela instituição. Na leitura do autor, a modelagem correta trata essa autorização como um registro auditável, com data e finalidade. Se a autorização fica perdida num log textual, ela até pode existir, mas não opera bem.

A lição dura por trás disso: originação de crédito não é uma tela bonita com chamada de bureaus, é uma cadeia de responsabilidade. Cada domínio precisa saber se decide, consulta, registra ou contabiliza.

### SCR e Cadastro Positivo

1. **Pela Res. CMN 5.037, a instituição pode consultar o SCR da Marina sem pedir nada a ela?**
- [x] Não; a consulta depende de autorização específica do cliente, _Art. 12. No sistema, a autorização vira registro auditável._
- [ ] Sim, o SCR é público, _O titular acessa os próprios dados; a instituição precisa de autorização._
- [ ] Sim, se ela já for cliente, _A norma não faz essa exceção._
- [ ] Só se o valor passar de R$ 200,00, _R$ 200,00 é o limiar de registro, não de consulta._

2. **Qual direito a Lei 12.414 dá à Marina sobre a nota de crédito?**
- [x] Pedir revisão de decisão tomada exclusivamente por meios automatizados, _Art. 5º, VI, ao lado do art. 20 da LGPD._
- [ ] Escolher o modelo que calcula a nota, _Ela tem direito a conhecer os principais critérios, não a escolher o modelo._
- [ ] Proibir o banco de reportar ao SCR, _O SCR é outra norma, com reporte obrigatório._
- [ ] Exigir aprovação automática, _Não existe esse direito._

## Perguntas que evitam desenho ruim

### Se a Marina já é cliente, o banco pode consultar o SCR dela sem pedir?

Não. Pela Res. CMN 5.037, art. 12, a consulta da instituição depende de autorização específica do cliente, e a norma não abre exceção para quem já tem conta. O art. 13 ainda pede comunicação prévia de que os dados irão ao SCR.

### Quem guarda os dados que Underwriting consulta?

Não assuma que é o próprio Underwriting. Quem decide não guarda todos os dados que consulta. Customer Credit Rating, Information Provider Operation e Financial Statement Assessment existem justamente para separar evidência, integração e avaliação especializada.

### O que muda no caso do Café Aurora Centro?

Além da conversa de produto e elegibilidade, entra balanço. Financial Statement Assessment avalia demonstrações financeiras e pode atualizar Customer Credit Rating. A decisão continua em Underwriting, com Credit Management fechando a visão de crédito do banco.

### 20. Rating, risco e perda esperada

_Rating, modelo e provisão são coisas diferentes: PD, LGD e EAD na prática e os três estágios da Res. CMN 4.966._

Rating, modelo e provisão vivem na mesma conversa, mas não fazem o mesmo trabalho. Rating é a leitura de risco do cliente hoje. Modelo é a regra que produz essa leitura e a probabilidade associada. Provisão é o dinheiro que o balanço separa para a perda esperada quando esse risco vira contabilidade.

## Três coisas que não podem morar na mesma gaveta

A pergunta perigosa nesta aula não é se o banco tem um score. É quem sabe explicar, meses depois, qual modelo gerou aquele rating, qual dado entrou na decisão, qual estágio contábil saiu do outro lado e qual lançamento foi feito no balanço.

No BIAN 14.0, **Customer Credit Rating** é o lugar natural para acompanhar a avaliação de crédito do cliente. O domínio tem padrão **Monitor**, 12 operações, BQs **Alerts**, **InternalReporting** e **ExternalReporting**, e o atributo `CustomerCreditRatingState`, descrito como o rating ou score atual, normalmente um ranking como 1 a 10. A feature chave fala em consolidar o uso dos produtos do banco que impacta o rating.

**Credit Risk Models** é outra coisa. O domínio tem padrão **Design**, 19 operações, BQs **FunctionalRequirements**, **Testing** e **Production**, e cobre desenvolvimento, manutenção, avaliação contínua e refinamento da coleção de modelos de crédito usados para derivar credit scoring.

**Customer Behavior Models** também entra na conversa, mas por outro ângulo: modelos de comportamento, incluindo análises de crédito e fraude. No cenário oficial **Process Card Account Delinquency Review**, view 55585, aparece a linha de vida Customer Behavior Models com as mensagens **Assess Probability of Default**, **Retrieve Card Probability of Default Model** e **Update Line of Credit**. Minha leitura: comportamento não substitui rating, ele alimenta uma parte da decisão.

> **Minha leitura prática:** Na prática, eu separo três responsabilidades: o rating diz o estado de risco do cliente, o modelo diz como esse estado foi calculado, e a provisão diz quanto desse risco precisa aparecer no balanço. Quando as três coisas ficam no mesmo sistema de produto, a auditoria vira arqueologia.

## O vocabulário mínimo para não misturar as peças

- **Rating:** leitura atual do risco do cliente, persistida e monitorada como estado, não como opinião solta dentro de uma jornada.
- **Modelo:** regra versionada que produz rating, PD ou outro insumo de risco, com requisitos, testes e produção separados.
- **Provisão:** reflexo contábil da perda esperada, calculada por estágio e lançada no balanço, não um atributo decorativo do contrato.
- **Score de aplicação, score de comportamento e safra:** trato como prática de mercado observada, não como definição normativa lida aqui.

## PD, LGD e EAD sem teatro estatístico

Basileia dá uma linguagem boa porque força unidade de medida. No Basel Framework em vigor desde 01/01/2023, `PD` e `LGD` são medidas em decimais, e `EAD` é medida em moeda, conforme `CRE31.2`. Para empresas, `CRE32.3` fala da PD de um ano da classe interna do tomador, e um tomador em default tem PD de 100%. `CRE32.15` trata LGD como percentual da EAD. `CRE32.29` define EAD bruta de provisões.

A fórmula didática que eu uso em sala é simples: **perda esperada = PD × LGD × EAD**. Tecnicamente, `CRE35.2` e `CRE35.3` separam `EL = PD × LGD` e valor de perda esperada como `EL × EAD`. Para quem está desenhando sistema, a forma expandida deixa claro o contrato de dados.

Exemplo ilustrativo e fictício, sem número de mercado: o carro da Marina tem EAD de R$ 45.000, PD de 0,02 e LGD de 0,40. A perda esperada é R$ 360. Sem a alienação fiduciária, a LGD seria maior. É por isso que garantia muda preço: ela não enfeita o cadastro, ela altera a expectativa de recuperação.

No varejo, Basileia permite olhar pools por características do tomador, da operação, como produto, garantia, loan to value e seasoning, e do atraso, conforme `CRE36.17`. Default aparece quando é improvável pagar sem executar garantia ou quando o atraso supera 90 dias, com nota permitindo ao supervisor até 180 dias no varejo, conforme `CRE36.68`.

### Termos do risco de crédito

- **PD**: Probabilidade de default, em decimal; no Basileia, de um ano para a classe do tomador; em default, 100%.
- **LGD**: Perda dado o default, em percentual da EAD; a garantia reduz.
- **EAD**: Exposição no default, em moeda, bruta de provisões.
- **Perda esperada**: PD × LGD × EAD (forma didática do CRE35).
- **Primeiro estágio (4.966)**: Sem aumento significativo de risco; provisão para os próximos 12 meses.
- **Segundo estágio (4.966)**: Risco aumentou significativamente (atraso acima de 30 dias já conta); provisão para todo o prazo esperado.
- **Terceiro estágio (4.966)**: Ativo problemático: atraso acima de 90 dias ou improvável pagar sem garantia; arrasta os instrumentos da mesma contraparte.

## Da probabilidade ao lançamento contábil

A fórmula só fica governável quando cada termo tem dono, versão e destino claros.

### 🤖 Modelos: cálculo de risco

- Credit Risk Models PD e versão do modelo (ai)
- Customer Behavior Models comportamento e atraso (ai)

### 👤 Cliente: estado de risco

- Customer Credit Rating CustomerCreditRatingState (data)
- Customer Position exposição do cliente (data)

### 📐 Perda esperada: contrato de dados

- PD decimal (compute)
- LGD decimal (compute)
- EAD moeda (compute)
- PD × LGD × EAD perda esperada (compute)

### 📚 Contabilidade: estágio e lançamento

- Estágio CMN 4.966 1, 2 ou 3 (security)
- Financial Accounting Track e lançamento (data)

### Fluxos

- crm -> pd: fornece probabilidade e versão
- cbm -> pd: alimenta comportamento observado
- ccr -> stage: estado de risco da contraparte
- cp -> ead: fornece exposição
- pd -> el: termo da fórmula
- lgd -> el: recuperação esperada e garantia
- ead -> el: valor exposto
- el -> stage: medido no horizonte do estágio
- stage -> fa: publica fato para lançamento

## Os três estágios da Res. CMN 4.966/2021
| Dimensão | Primeiro estágio | Segundo estágio | Terceiro estágio |
| --- | --- | --- | --- |
| Gatilho | Sem aumento significativo de risco desde o reconhecimento inicial. | Risco aumentou significativamente, ou o ativo deixou de ser problemático. | Ativo problemático: atraso superior a 90 dias ou indicativo de que a obrigação não será integralmente honrada sem recorrer a garantias. |
| Horizonte da provisão | Probabilidade nos próximos 12 meses, conforme art. 47. | Probabilidade durante todo o prazo esperado, conforme art. 47. | Provisão considerando que o ativo já é problemático, conforme art. 47. |
| Regra que costuma ser esquecida | Atraso superior a 30 dias já é aumento significativo de risco, admitidos até 60 dias com evidência comprovada. | A probabilidade deve ser consistente para todos os instrumentos da mesma contraparte (art. 40, § 3º, vale em qualquer estágio). | Quando um instrumento vai para o terceiro estágio, todos os instrumentos da mesma contraparte vão para o terceiro estágio. |

## Onde a provisão entra no mapa do BIAN

Aqui existe uma ausência importante. Eu procurei por `provision` e `impair` nos nomes do BIAN 14.0 e não achei Service Domain de provisão. Minha leitura de arquitetura é esta: **Credit Risk Models** e **Customer Position** alimentam o cálculo, e o resultado vai para **Financial Accounting**, no padrão **Track**, para lançar. Quem calcula o estágio publica o fato.

Isso parece detalhe, mas evita um erro caro. Provisão não é uma coluna que cada produto calcula sozinho. A Res. CMN 4.966/2021 olha a contraparte. O art. 37, § 5º, diz que quando um instrumento vai para o terceiro estágio, todos os instrumentos da mesma contraparte vão para o terceiro estágio. O art. 40 diz que a perda esperada considera a probabilidade de o instrumento virar problemático e a expectativa de recuperação, com custos e garantias. O § 3º exige probabilidade consistente para todos os instrumentos da mesma contraparte.

Também há armadilhas de nome. **Counterparty Risk** trata rating de contraparte ligado a atividade de transação e rating externo. **Credit Risk Operations** monitora limites de contraparte de trading, como no caso em que uma mesa checa uma proposta contra limites de crédito de contraparte. Isso não é o limite do cliente de varejo. **Business Risk Models** olha exposições comerciais ou de negócio e não tem API na v14. Para esta aula, o centro do varejo está em Customer Credit Rating, Credit Risk Models, Customer Behavior Models, Customer Position e Financial Accounting.

## Como eu desenharia o fluxo sem inventar domínio

1. **Separe o rating do modelo**: Grave o estado em Customer Credit Rating e mantenha a regra versionada em Credit Risk Models. O rating é resultado monitorado, não o código do modelo.

2. **Calcule PD, LGD e EAD como contrato de dados**: PD e LGD entram em decimal, EAD entra em moeda. Essa separação parece básica, mas é o que evita fórmula escondida dentro de tela.

3. **Publique o estágio por contraparte**: O estágio não deve nascer preso a um contrato individual. Quando um instrumento entra no terceiro estágio, a arquitetura precisa enxergar os demais instrumentos da mesma contraparte.

4. **Envie o fato contábil para Financial Accounting**: O cálculo de risco produz o fato. Financial Accounting registra. Essa fronteira reduz acoplamento e deixa claro quem responde por modelo, estágio e lançamento.

### O carro da Marina (números ilustrativos)

1. **EAD de R$ 45.000, PD de 0,02 e LGD de 0,40. Qual é a perda esperada?**
- [x] R$ 360, _0,02 × 0,40 × 45.000 = 360._
- [ ] R$ 900, _Esse seria PD × EAD, sem a LGD._
- [ ] R$ 18.000, _Esse seria LGD × EAD, sem a PD._
- [ ] R$ 3.600, _Erro de uma casa decimal._

2. **O cartão da Marina vai para o terceiro estágio. E o financiamento do carro, em dia?**
- [x] Vai junto para o terceiro estágio, _Res. CMN 4.966, art. 37, § 5º: todos os instrumentos da mesma contraparte._
- [ ] Fica no primeiro estágio porque está em dia, _A regra olha a contraparte, não só o contrato._
- [ ] Vai para o segundo estágio, _A norma manda para o terceiro._
- [ ] É baixado para prejuízo, _Baixa é outra decisão (art. 49)._

## Perguntas que aparecem na arquitetura

### Score de aplicação e score de comportamento são BIAN?

Eu trataria como prática de mercado, não como definição normativa lida aqui. O mapa ajuda a posicionar a responsabilidade: aplicação costuma nascer na originação, comportamento aparece com histórico de uso, atraso e eventos observados.

### Existe Service Domain de provisão no BIAN 14.0?

Não. Eu procurei por `provision` e `impair` nos nomes da v14 e não achei. O desenho que uso é cálculo alimentado por risco e posição do cliente, com fato enviado para Financial Accounting.

### Modelos por produto aparecem em cenários oficiais?

Sim. Há mensagens como **Retrieve Merchandising Lending Risk Model**, view 55506, e **Retrieve Buy Now Pay Later Risk Model**, view 55435. Renovação de empréstimo usa **Retrieve Repayment Details of Loan to Be Renewed**, view 55456.

## Veredito

Eu não começaria essa arquitetura pelo motor de score. Começaria pela pergunta de rastreabilidade: para cada decisão, consigo recuperar rating, modelo, versão, PD, LGD, EAD, estágio, contraparte e lançamento contábil? Se a resposta for não, o problema não é estatístico, é de fronteira de domínio.

**Rating:** clear

### 21. Limites e a árvore de crédito: franquia, grupo econômico e conglomerado

_O limite global, as linhas penduradas nele e quando duas empresas viram um único cliente para o banco._

A pergunta “quanto o banco me empresta?” parece simples, mas quase nunca tem uma resposta só. Na prática, ela vira uma árvore: grupo, cliente, limite global, linhas, produtos e operações. Se você não separa essas camadas, confunde limite aprovado com dinheiro disponível e chama de cliente aquilo que a norma pode tratar como grupo conectado.

## A árvore antes do produto

Marina tem um limite global interno sem garantia real de R$ 50 mil. Dentro dele, o banco repartiu cartão de R$ 12 mil, cheque especial de R$ 2 mil, consignado de R$ 20 mil e R$ 16 mil ainda disponíveis.

Esse exemplo é pequeno de propósito. Ele mostra que “limite” não é uma coluna única no cadastro. Existe o limite global do cliente, existem limites por produto, existe capacidade de pagamento avaliada em Underwriting, existe margem consignável quando a lei entra no desenho, e existem teto de grupo e concentração quando a exposição deixa de ser só individual.

Na minha leitura, juntar isso numa árvore é a forma mais honesta de ensinar o assunto: grupo, cliente, limite global, linhas, produtos e operações. O BIAN não diz que Marina deve ser modelada assim. A ficha de Credit Facility fala em cliente corporativo. Usar a mesma árvore para uma pessoa física é adaptação didática minha, útil porque o mecanismo mental é o mesmo.

Um limite tem três estados que todo sistema deveria deixar explícitos: usado, reservado e disponível. O reservado aparece no BIAN como `AmountBlockAmount`. Sem isso, você aprova duas coisas ao mesmo tempo e só descobre depois que a conta não fechava.

> **Na prática:** Na prática, eu não começo pelo produto. Começo perguntando qual exposição máxima o banco aceita para aquela pessoa ou grupo, quais linhas consomem esse teto, o que já está usado, o que está bloqueado, e qual regra impede um aumento automático. Produto vem depois.

## As respostas possíveis para a mesma pergunta

- **Limite global do cliente:** teto interno de exposição que o banco aceita assumir com aquele cliente.
- **Limite por produto:** cartão, cheque especial, capital de giro, conta garantida ou antecipação consomem partes diferentes do desenho.
- **Capacidade de pagamento:** Underwriting responde se a operação cabe no fluxo do cliente, não só se existe limite cadastrado.
- **Margem consignável:** quando aplicável, a lei cria uma trava própria, separada da vontade comercial do banco.
- **Grupo e concentração:** a Res. 4.557/2017 e a Res. 4.677/2018 mudam a pergunta de “este cliente cabe?” para “este conjunto conectado cabe?”.

## Onde o BIAN encaixa a linha de crédito

O Service Domain central aqui é Credit Facility. Ele é `Fulfill`, tem 10 operações e inclui os Behavior Qualifiers Charge e CreditAllocation. A chamada que interessa para a aula é `POST /CreditFacility/{creditfacilityid}/CreditAllocation/Initiate`.

O Control Record é CreditLineFacility. Nele, os campos que fazem a árvore respirar são `CreditFacilityAmount`, `AvailableAmount`, `AmountBlockAmount` e `AssociatedPartyReference`. No BQ CreditAllocation aparecem `ParentCreditFacilityReference`, `SubordinateCreditFacilityReference` e `AssociatedCollateralAssetManagementReference`. Traduzindo para arquitetura: uma linha pode ficar embaixo de outra linha, pode consumir o limite de cima e pode estar associada a uma garantia.

A própria ficha do BIAN diz que Credit Facilities podem ter hierarquia e ficam sob o Credit Limit geral do cliente, o máximo interno de exposição que o banco aceita ter com ele. A mesma ficha também permite que esse Credit Limit cubra mais de um cliente, normalmente dentro de um customer group.

O cenário oficial “Handle Request for Credit Facility”, view 55351, traz passos como “Confirm Request Is within Customer Credit Limit”, “Attach Credit Facility in Credit Facility Hierarchy” e “Get Approval from Credit Committee”. Ele ainda lista Payment Order, que em BIAN 14.0 é obsoleto. Use isso como sinal de leitura crítica, não como licença para modelar domínio antigo.

## A árvore de crédito do grupo do Rafael

Valores fictícios para mostrar hierarquia, consumo de limite e partes associadas. Rede Aurora e Torra Boa ficam marcadas para análise, não entram automaticamente no grupo.

### 👤 Cliente: Rafael e empresas

- Grupo Rafael limite R$ 600 mil (user)
- Rafael PF cartão R$ 30 mil veículo R$ 70 mil (data)
- Café Aurora Centro capital de giro R$ 200 mil 90% usado (data)
- Café Aurora Shopping conta garantida R$ 200 mil (data)
- Torra Boa 50% Rafael a analisar (external)
- Rede Aurora franqueadora a analisar (external)

### 🔐 Crédito: Linhas e vínculos

- Antecipação de recebíveis R$ 100 mil cessão fiduciária registrada (security)
- Rafael avalista AssociatedPartyReference (security)

### Fluxos

- grupo -> centro: consome limite do grupo
- grupo -> shopping: controle de 100%
- grupo -> rafael: exposição pessoa física
- centro -> antecipacao: linha com garantia associada
- aval -> centro: avalista dos contratos
- aval -> shopping: avalista dos contratos
- grupo -> torra: controle ou dependência econômica a analisar
- grupo -> rede: franquia não basta por definição

### A árvore e o grupo

1. **Segundo a ficha v14 do Credit Facility, o overall Credit Limit…**
- [x] é o máximo interno de exposição com o cliente e pode cobrir clientes de um mesmo grupo, _As facilities formam hierarquia debaixo dele._
- [ ] é o limite regulatório de 25% do Nível I, _Esse é o teto da Res. 4.677, outra coisa._
- [ ] é o limite do cartão, _O cartão é um galho da árvore._
- [ ] não existe na v14, _Está na ficha do Credit Facility._

2. **A Rede Aurora (franqueadora, que o Rafael não controla) é automaticamente o mesmo cliente que o Café Aurora Centro?**
- [x] Não; só se houver dependência econômica relevante, analisada e documentada, _Franquia não é grupo por definição (leitura do autor sobre as Res. 4.557 e 4.677)._
- [ ] Sim, a marca é a mesma, _A norma olha controle e dependência, não marca._
- [ ] Sim, toda franquia é controlada pela franqueadora, _No caso, não há controle._
- [ ] Nunca, empresa pequena está fora da regra, _O porte do cliente não tira a análise._

3. **O Rafael tem exatamente 50% da Torra Boa. Isso, sozinho, é controle pelo art. 22, § 2º, da Res. 4.557?**
- [x] Não; o critério é mais de 50% do capital votante, e o vínculo teria de vir de outro critério ou de dependência econômica, _Acordo de voto, poder de eleger administradores, gestão ou dependência econômica podem ligar as duas._
- [ ] Sim, 50% já é controle, _A norma fala em mais de 50%._
- [ ] Sim, porque o sócio é cunhado, _Parentesco não está entre os critérios citados._
- [ ] A Res. 4.557 não trata de controle, _O art. 22 define controle._

4. **O conglomerado prudencial (Res. CMN 4.950) é de quem?**
- [x] Do banco: a instituição e as entidades que ela controla, _O grupo de contrapartes conectadas é do cliente._
- [ ] Do cliente e das empresas dele, _Isso é o grupo de contrapartes conectadas._
- [ ] Da franqueadora e das franquias, _Franquia não define conglomerado._
- [ ] Do Banco Central, _O BC supervisiona, não forma conglomerado._

## Rafael mostra onde a árvore fica séria

Rafael, 41 anos, tem duas lojas fictícias. O Café Aurora Centro é microempresa e franquia da Rede Aurora, a franqueadora, que é outra empresa e não é controlada por ele. A loja tem capital de giro de R$ 200 mil, com 90% usado, e antecipação de recebíveis de cartão de R$ 100 mil com cessão fiduciária de recebíveis registrados.

O Café Aurora Shopping tem CNPJ próprio e é 100% dele. Ali existe conta garantida de R$ 200 mil. Rafael também tem 50% da Torra Boa, torrefação com o cunhado, que fornece os cafés das lojas. Como pessoa física, Rafael é avalista dos contratos das lojas, tem cartão de R$ 30 mil e financiamento de veículo de R$ 70 mil. O limite do grupo no banco fictício é R$ 600 mil.

A leitura importante: franquia não é grupo econômico por definição. A Rede Aurora não é controlada por Rafael, então só entraria no grupo se houvesse dependência econômica relevante, analisada e documentada. A Torra Boa também exige cuidado. Cinquenta por cento não é “mais de 50%”, então o vínculo viria de outro critério de controle do art. 22 da Res. 4.557/2017, ou de dependência econômica, já que ela fornece os cafés das lojas. O Café Aurora Shopping entra pelo controle de 100%.

## Grupo do cliente não é conglomerado do banco
| Dimensão | Grupo de contrapartes conectadas | Conglomerado prudencial |
| --- | --- | --- |
| De quem é | Do cliente ou das contrapartes que compartilham risco de crédito. | Do banco, formado pela instituição e entidades que ela controla. |
| Base regulatória nesta aula | Res. 4.557/2017, art. 22, e Res. 4.677/2018, art. 7º. | Res. CMN 4.950/2021. |
| Pergunta operacional | Essas pessoas ou empresas viram uma única contraparte para risco de crédito? | Quais entidades entram no perímetro consolidado da instituição financeira? |
| Erro comum | Tratar franquia, sociedade de 50% ou fornecedor como grupo automático sem análise documentada. | Chamar o grupo econômico do cliente de conglomerado prudencial. |

## Regulação entra como trava, não como nota de rodapé

A Res. 4.557/2017, art. 22, diz que contrapartes conectadas constituem uma única contraparte para o gerenciamento do risco de crédito. Conectadas são aquelas que compartilham risco, inclusive por relação de controle. Controle aparece quando há mais de 50% do capital votante, acordo de voto com preponderância, poder de eleger ou destituir a maioria dos administradores, ou preponderância na gestão operacional. Existe exceção documentada, e o BCB pode determinar que contrapartes são conectadas.

A Res. 4.677/2018 leva isso para grandes exposições. Para instituições S1 a S4, a exposição total perante um mesmo cliente fica limitada a 25% do Nível I do PR, com deliberação de conselho ou diretoria acima de 20%. Exposição concentrada é igual ou maior que 10% do Nível I, e as concentradas somadas ficam limitadas a 600%. Para exposição igual ou superior a 5% do Nível I, a dependência econômica pode presumir compartilhamento de risco.

S5 tem regra própria: 25% do PR do S5. O cumprimento é consolidado no conglomerado prudencial. A Res. CMN 4.950/2021 ajuda a separar as coisas: conglomerado prudencial é do banco. Grupo de contrapartes conectadas é do cliente.

## Como eu desenharia a checagem

1. **1. Recupere a estrutura jurídica**: Use Legal Entity Directory para manter ownership, subsidiárias e parcerias. O cenário “Handle Request for Corporate Loan”, view 55015, inclui “Retrieve Corporate Ownership Structure” e “Retrieve Credit Facilities of This Customer”.

2. **2. Separe relacionamento de controle**: Party Reference Data Directory mantém papéis, associações e relacionamentos. Isso não decide sozinho o grupo de risco. A decisão de controle ou dependência precisa de regra e evidência.

3. **3. Calcule exposição consolidada**: Customer Position tem o BQ Credit e a chamada `POST /CustomerPosition/{customerpositionid}/Credit/Evaluate`. A key feature é derivar exposição de crédito consolidada, atual e projetada.

4. **4. Cheque limite e bloqueios**: Credit Facility responde onde a linha entra na hierarquia, quanto está disponível e quanto está reservado em `AmountBlockAmount`. Esse é o ponto em que aprovação comercial encontra controle operacional.

### Necessidade e domínio

- **Limite global e linhas em hierarquia** → Credit Facility
- **Exposição de crédito consolidada do cliente** → Customer Position
- **Estrutura societária e participações** → Legal Entity Directory
- **Papéis e vínculos entre pessoas** → Party Reference Data Directory

## Perguntas que costumam quebrar o desenho

### Existe um Service Domain v14 específico para cheque especial, consignado ou provisão?

Não. Eu procurei nos nomes da v14 e não achei nenhum dos três. Não invente um domínio para deixar o mapa bonito: modele a linha, o produto e a operação com os domínios e campos que existem, e registre a composição num ADR.

### Limit and Exposure Management resolve tudo?

Não. A ficha fala em supervisionar limites e exposições corporativas para atividade combinada, mas em BIAN 14.0 não há Semantic API e o domínio aparece em um único cenário v14, o de underwriting de garantia bancária (view 55765). Na minha leitura, “corporate limits” são limites consolidados do banco, e o BIAN não esclarece o suficiente para fazer dele o centro da solução.

### O limite de cheque especial pode aumentar sozinho?

Pela Res. 4.765, art. 4º, o limite deve ser compatível com o perfil de risco. A instituição pode reduzir com aviso prévio de 30 dias. Aumento exige autorização do cliente a cada oferta. Redução sem aviso prévio cabe quando há deterioração do risco, com comunicação até o momento da redução.

## Ficha rápida

- **Service Domain central:** Credit Facility, com Control Record CreditLineFacility e BQ CreditAllocation.
- **Exposição consolidada:** Customer Position, BQ Credit, com `POST /CustomerPosition/{customerpositionid}/Credit/Evaluate`.
- **Estrutura jurídica:** Legal Entity Directory e Party Reference Data Directory ajudam a manter ownership, associações e relacionamentos.
- **Grandes exposições (S1 a S4):** Res. 4.677: até 25% do Nível I por cliente, deliberação acima de 20%, concentradas a partir de 10% e somadas até 600%; cumprimento consolidado no conglomerado prudencial.

### 22. Garantias, contrato e desembolso

_O bem, a alocação do bem ao contrato e a administração do bem, e depois CET, contrato, desembolso e portabilidade._

Garantia não é um anexo jurídico colado no fim do crédito. É uma cadeia operacional: alguém descreve o bem, alguém aloca esse valor a um contrato, alguém administra documentação, seguro, avaliação e liberação, e só depois o dinheiro deveria sair.

## O bem tem dono antes de virar garantia

No carro da Marina, a história parece simples: veículo de R$ 75 mil, entrada de R$ 30 mil, R$ 45 mil financiados em 48 parcelas, com alienação fiduciária. A conta do autor é direta: R$ 45 mil sobre R$ 75 mil dá 60% de loan to value. No apartamento, R$ 300 mil financiados sobre R$ 400 mil dão 75%. Esses números são fictícios, mas a lição é real.

O erro clássico que eu já vi em desenho de crédito é copiar o valor do bem em cada contrato. Parece prático no primeiro sprint. Depois vira divergência permanente: o carro muda de valor, o seguro vence, a documentação é atualizada, e cada contrato guarda uma verdade diferente.

No BIAN 14.0, a leitura que faz sentido começa em Party Asset Directory. Ele registra bens de terceiros que interessam ao banco quando são dados em garantia. Na ficha do domínio, antes do financiamento do carro, o cliente informa os dados do carro. As operações ficam em Behavior Qualifiers como AssetProperties, AssetEstimatedValue, AssetInsurance e AssetMaintenance. Um exemplo concreto é `POST /PartyAssetDirectory/{id}/AssetEstimatedValue/Register`.

Esse domínio não decide se o crédito será aprovado. Ele mantém o cadastro do bem. Parece menor, mas é o que impede o contrato de virar o único lugar onde o banco sabe que o bem existe.

> **Na prática:** Na prática, eu desenho garantia como estado operacional, não como campo de contrato. Se o bem, a alocação e a administração ficam misturados, você perde rastreabilidade no exato momento em que mais precisa dela: renegociação, portabilidade, inadimplência, execução ou auditoria.

## Do carro da Marina ao desembolso

A ordem é uma leitura do autor para ensinar a cadeia operacional. O repositório do BIAN lista linhas de vida dos cenários, não as setas deste fluxo.

### 👤 Cliente: Marina

- Marina carro de R$ 75 mil (user)

### 📋 Cadastro do bem: Party Asset Directory

- Party Asset Directory AssetEstimatedValue (data)

### 🔐 Garantia: alocação e administração

- Collateral Allocation Management R$ 45 mil alocados (security)
- Collateral Asset Administration avaliação, seguro, documentação (security)

### 📄 Contrato: termos e CET

- Customer Agreement termos mestres (data)
- Sales Product Agreement produto e CET (data)

### 🏪 Loja: recebimento

- Disbursement pagamento à loja (compute)
- Loja recebe o valor (external)

### Fluxos

- marina -> asset: informa dados do carro
- asset -> allocation: bem vira garantia elegível
- allocation -> admin: valor reservado e acompanhado
- admin -> master: documentação sustenta os termos
- master -> product: produto subordinado ao contrato mestre
- product -> disbursement: contrato assinado libera pagamento
- disbursement -> merchant: cenário 55527 paga a loja

## Alocar não é administrar

Depois que o bem existe como registro, ele precisa ser alocado. Collateral Allocation Management, em BIAN 14.0, é o domínio que aloca um bem dado em garantia a um ou mais empréstimos e determina a parcela do valor que pode, ou ainda pode, ser usada como garantia. É um domínio Allocate, com 4 operações no YAML v14. Os atributos importantes para o arquiteto são `CollateralAllocationAmount`, `CollateralEarmarkedAmount`, `CollateralCurrentValueAmount` e `EvaluateAcceptabilityResultDescription`.

Aqui entra a alienação fiduciária. No carro, o cliente transfere a propriedade fiduciária de um bem durável ao banco. No imóvel, a Lei 9.514/1997, com redação da Lei 14.711/2023, diz no art. 22 que a alienação fiduciária transfere ao credor a propriedade resolúvel, em garantia de obrigação própria ou de terceiro. Se a dívida vence e não é paga, o art. 26 trata da consolidação da propriedade em nome do credor, com intimação pelo Registro de Imóveis para pagar em 15 dias. O art. 27 trata do leilão público em até 60 dias do registro da consolidação e do segundo leilão em 15 dias.

Administrar é outro trabalho. Collateral Asset Administration é um domínio Administer, com 12 operações e Behavior Qualifiers como Valuation e Maintenance. É onde entram avaliações programadas e pontuais, títulos, documentação e obrigações do dono, como segurar a casa. Um exemplo concreto é `POST /CollateralAssetAdministration/{id}/Valuation/Create`.

## Onde cada coisa mora

- Party Asset Directory guarda o bem de terceiro que interessa ao banco: carro, imóvel ou recebíveis registrados.
- Collateral Allocation Management reserva valor de garantia para um ou mais empréstimos e mostra quanto ainda pode ser usado.
- Collateral Asset Administration acompanha avaliação, documentação, manutenção e obrigação de seguro.
- Avalista não exige um domínio próprio de aval de pessoa física. Rafael aparece como parte associada, por exemplo via `AssociatedPartyReference` no Credit Facility.
- Bank Guarantee é armadilha neste ponto. Em BIAN 14.0, Bank Guarantee com `Transact` é instrumento de comércio exterior e project finance, não aval.

### A contratação do carro da Marina

Ordene os passos (ordem do autor).

1. Party Asset Directory registra o carro
2. Collateral Asset Administration avalia o bem
3. Underwriting decide
4. Collateral Allocation Management aloca o carro ao contrato
5. Sales Product Agreement formaliza, com o CET informado antes
6. Merchandising Loan abre o financiamento
7. Disbursement paga a loja

## Recebíveis, contrato e CET entram na mesma cadeia

O Café Aurora Centro antecipa R$ 100 mil com cessão fiduciária de recebíveis registrados. O gancho oficial do BIAN é o cenário 55535, Conduct Corporate Loan Collateral Due Diligence. A linha passa por obter lista de recebíveis de devedores atuais do cliente, registrar recebíveis como Party Asset, preparar o acordo de penhor dos recebíveis (`Prepare Agreement on Pledging of Debtors Receivables`) e determinar o mix de alocação de garantia.

No Brasil, recebível de cartão tem regra própria. A Resolução 4.734/2019 separa recebíveis constituídos, que vêm de transações já feitas, e recebíveis a constituir, que vêm de transações futuras. Desconto é cessão definitiva. Operação garantida por recebíveis é outra coisa. Os recebíveis precisam estar registrados em sistemas de registro, o contrato especifica os recebíveis e o valor mantido em garantia, e a instituição comanda gravames e ônus na registradora. A Resolução BCB 264/2022 trata do registro com interoperabilidade entre sistemas de registro.

Depois vem o contrato. Customer Agreement guarda os termos mestres com `Agree Terms`. Sales Product Agreement guarda os termos do produto, subordinados ao contrato mestre, também com `Agree Terms`. CET não é rodapé comercial. Pela Resolução CMN 4.881/2020, vigente desde 1º/02/2021, ele vale para pessoa natural, empresário individual, microempresa e empresa de pequeno porte. Consolida encargos e despesas, incluindo tarifas, tributos, seguros e serviços de terceiros, expresso como taxa percentual anual com duas casas decimais.

## Três garantias, três cuidados de arquitetura
| Dimensão | Carro da Marina | Apartamento | Recebíveis do Café Aurora Centro |
| --- | --- | --- | --- |
| Valor fictício | Bem de R$ 75 mil, R$ 45 mil financiados, 60% de loan to value pela conta do autor. | Imóvel de R$ 400 mil, R$ 300 mil financiados, 75% de loan to value pela conta do autor. | Antecipação de R$ 100 mil com cessão fiduciária de recebíveis registrados. |
| Domínio que não pode faltar | Party Asset Directory para o cadastro do carro antes da alocação. | Collateral Asset Administration para avaliação, seguro e documentação. | Party Asset Directory e Collateral Allocation Management para registrar e alocar os recebíveis. |
| Risco de modelagem | Copiar valor do carro em cada contrato e perder a fonte única do bem. | Tratar execução, seguro e avaliação como texto livre sem estado operacional. | Confundir desconto definitivo com operação garantida por recebíveis. |

## Desembolso e portabilidade fecham o ciclo

Desembolso não é um `update status` no contrato. Disbursement, em BIAN 14.0, usa `Transact` e é modelado como centro de serviço porque muitos bancos desembolsam por uma unidade especializada. No carro, o cenário 55527 paga a loja. Ele ainda traz o rótulo `Confirm Payment Order to Merchant`, mas Payment Order é nome obsoleto em BIAN 14.0. O cuidado aqui é não trazer o nome antigo para o seu mapa novo.

Também existe o cenário 55660, Perform Closing of Uncollateralised Consumer Loan, com passos como `Calculate Repayment Schedule`, `Present Loan Offer to Customer and Get Signature` e `Register Loan with External Agencies`. Mesmo sendo sem garantia, ele ajuda a lembrar que fechamento de crédito envolve agenda, assinatura e registro externo quando aplicável.

Portabilidade muda a pergunta. Não é só liquidar um contrato, é transferir uma dívida com regras de prazo, informação e custo. Pela Resolução CMN 5.057/2022, vigente desde 1º/03/2023, a credora original deve garantir a portabilidade. A troca de informações ocorre por sistema eletrônico de registradora ou pela infraestrutura do Open Finance. Valor e prazo na proponente não superam saldo devedor e prazo remanescente. A proposta traz taxa, CET, prazo e prestações. A credora original pede a transferência em até 5 dias úteis pela registradora ou 3 dias úteis pelo Open Finance. Custos não podem ser repassados ao devedor, e a regra não se aplica a cartão consignado.

## Como eu mapearia a jornada

1. **Registre o bem uma vez**: Comece em Party Asset Directory. Carro, imóvel e recebíveis precisam ter dono operacional antes de aparecerem como garantia de um contrato.

2. **Aloque valor, não texto**: Use Collateral Allocation Management para reservar valor e acompanhar quanto ainda pode sustentar crédito. O campo livre no contrato não resolve isso.

3. **Administre a vida do bem**: Avaliação, seguro, manutenção, título e documentação pertencem à administração da garantia. Se isso fica sem estado, a falha aparece tarde.

4. **Separe contrato mestre e produto**: Customer Agreement segura os termos mestres. Sales Product Agreement segura o produto, o CET e as condições subordinadas à relação principal.

5. **Só então desembolse**: Disbursement deve receber uma cadeia pronta: garantia registrada, alocação aceitável, contrato assinado e informação de pagamento correta.

### Checagem rápida

1. **O Rafael é avalista dos contratos das lojas. Onde ele aparece no BIAN v14?**
- [x] Como parte associada ao crédito, sem domínio próprio de aval, _`AssociatedPartyReference` e 'Retrieve Owner or Guarantor Credit Score'._
- [ ] No Bank Guarantee, _Bank Guarantee é instrumento de comércio exterior e project finance._
- [ ] No Collections, _Collections cuida de liquidar garantias de contas problemáticas._
- [ ] No Customer Agreement, como titular, _Ele garante; o titular é a empresa._

2. **Na portabilidade (Res. CMN 5.057), quem paga os custos da troca?**
- [x] Não podem ser repassados ao devedor, _Art. 15._
- [ ] A Marina, na primeira parcela, _A norma veda o repasse._
- [ ] O Banco Central, _O BC não paga a troca._
- [ ] A registradora, _A registradora é infraestrutura, não pagadora._

## Perguntas que evitam desenho errado

### Onde entra Rafael como avalista?

Não há domínio de aval de pessoa física neste recorte. Rafael aparece como parte associada. O exemplo permitido é `AssociatedPartyReference` no Credit Facility, e o cenário 54972 cita `Retrieve Owner or Guarantor Credit Score`.

### Posso usar Bank Guarantee para aval?

Não. Bank Guarantee, em BIAN 14.0, é instrumento de comércio exterior e project finance. Usar esse domínio para aval de Rafael mistura conceitos e atrapalha o mapa.

### E arrependimento no aplicativo?

O CDC, art. 49, fala em desistência em 7 dias quando a contratação ocorre fora do estabelecimento comercial, com devolução imediata e corrigida. A aplicação específica a contrato feito por aplicativo não está coberta nesta aula.

## Veredito

Minha recomendação é simples: modele garantia como três responsabilidades separadas. O bem fica no Party Asset Directory, a reserva de valor fica no Collateral Allocation Management, e a vida operacional da garantia fica no Collateral Asset Administration. Contrato, CET, desembolso e portabilidade vêm depois, com cada regra no seu lugar. O desenho fica menos conveniente no primeiro quadro, mas muito mais auditável quando alguém precisa explicar por que aquele valor sustentava aquele crédito.

**Rating:** strong

### 23. A carteira, o atraso e a recuperação

_Como o banco olha a carteira inteira e quem é dono de cada estágio, do primeiro dia de atraso à baixa._

O atraso não nasce na cobrança. Ele aparece primeiro como mudança de estado da conta, depois vira decisão de risco, depois vira recuperação, e só no fim pode virar baixa. Nesta aula eu quero separar essas fronteiras, porque é aí que muita arquitetura bancária começa a misturar leitura de carteira com escrita de conta.

## Carteira é leitura ampla, não comando operacional

Quando eu olho a carteira inteira, eu não estou procurando o endpoint que muda a vida de um contrato. Estou procurando o livro consolidado do banco. No BIAN 14, Bank Portfolio Administration consolida, ratifica, corrige e apresenta a informação do `book of business` consolidado do banco. Bank Portfolio Analysis dá visões analíticas desse livro. Economic Capital combina riscos de tipos diferentes na posição de risco consolidada.

Esses três domínios, nesta leitura, servem para enxergar. Eles não têm Semantic API na v14, e por isso eu não atribuo padrão funcional a eles. Isso importa porque a tentação comum é transformar qualquer visão de carteira em dono da decisão. A carteira pode mostrar concentração, envelhecimento, exposição, recorte por produto ou recorte por safra. Mas mostrar não é executar.

Asset And Liability Management tem outra natureza: define e direciona as políticas de ativos e passivos e sanciona grandes transações. Financial Accounting lança. Asset Securitization trata a seleção e a securitização de ativos, com o cenário `Process Selection of Loans for Securitization`, incluindo `Calculate Probability of Default` e `Assign Loans to SPV`. Mesmo assim, isso não autoriza misturar securitização com cobrança, nem contabilidade com recuperação.

A armadilha clássica: Customer Portfolio e Product Portfolio analisam rentabilidade e desempenho por segmento e por produto. Eles não são carteira de risco.

## A regra mental da aula

- Leia a carteira de forma ampla, mas escreva o estado da conta por uma fronteira estreita.
- Um domínio pode explicar o risco sem ser dono da ação que altera o contrato.
- Collections, no BIAN, não é cobrança em geral. É recuperação ou liquidação de colateral contra contas problemáticas.
- Não existe Service Domain v14 de provisão. Provisão é tratamento contábil e regulatório, não um domínio inventado no mapa.

> **Minha leitura de arquitetura:** Na prática, eu desenho essa parte com uma regra simples: relatório pode atravessar domínios, comando não. Se um dashboard de carteira enxerga atraso, exposição, capital e concentração, ótimo. Mas a atualização de linha, a promessa de pagamento, a reestruturação, a execução de garantia e a baixa precisam ter donos explícitos, porque é isso que você audita quando algo dá errado.

## A esteira do atraso com um dono por estágio

A ordem é leitura do autor para ensinar a jornada. O repositório do BIAN lista linhas de vida dos cenários, não setas obrigatórias entre etapas.

### 📊 Carteira: visão consolidada

- Bank Portfolio Administration book of business (data)
- Bank Portfolio Analysis visões analíticas (data)

### 💳 Cartão: atraso inicial

- Customer Billing fatura e lembrete (compute)
- Delinquent Account Handling contato e redução de linha (compute)
- Card Collections promessa e cobrança de cartão (compute)

### 🛠 Recuperação: dificuldade real

- Account Recovery negociação e writedown (compute)
- Collections liquidação de colateral (compute)

### 📒 Contábil: registro

- Financial Accounting lançamento e baixa (data)

### Fluxos

- portfolio -> analysis: analisa carteira
- billing -> delinq: faixas de 30 dias
- delinq -> cardcol: promessa ou transferência
- cardcol -> recovery: conta em dificuldade
- recovery -> collections: garantia ou factoring
- recovery -> accounting: baixa parcial ou total
- analysis -> delinq: sinal, não comando

### O atraso no cartão, do primeiro dia à baixa

Ordene as etapas (sequência do autor sobre os cenários oficiais).

1. A fatura rola o saldo para a faixa de 30 dias
2. Delinquent Account Handling faz o contato
3. Delinquent Account Handling reduz ou bloqueia a linha
4. Card Collections registra a promessa de pagamento
5. Account Recovery avalia a baixa
6. Financial Accounting lança a baixa

## O atraso no cartão passa por estados, não por um bloco chamado cobrança

No cartão, o atraso fica didático porque os cenários do BIAN expõem a sequência operacional. `Process Card Billing` inclui `Roll Balance Ageing Buckets by 30 Days`, `Calculate Interest` e `Calculate Delinquency Fees`. O mesmo cenário ainda lista Credit Card Position Keeping, mas esse nome não tem ficha na v14. O nome v14 que você deve usar para o domínio renomeado é Card Transaction Tracking.

Depois vem a revisão da inadimplência da conta de cartão. `Process Card Account Delinquency Review` inclui `Update Line of Credit`, `Initiate Dunning Cycle` e `Transfer to Collection`. Aqui aparece um ponto de arquitetura concreto: Delinquent Account Handling pode precisar reduzir a linha de crédito, bloquear a conta para não aumentar o risco, cancelar a conta e transferir para Collections. O YAML v14 tem 16 operações, com BQs Assessment, Contact, Payment e Resolution. O exemplo `POST /DelinquentAccountHandling/{id}/Contact/Initiate` deixa claro que contato não é relatório, é processo.

Card Collections continua a jornada do cartão, com BQs Assignment, PaymentTerms, Payment e Resolution. A ficha cita conta de cartão cancelada quando a idade do saldo passa do limite da política, normalmente 90 dias. `Process Card Collection` inclui `Determine Collection Strategy`, `Record Promise to Pay` e `Cancel Card Account`. Depois, `Process Periodic Review of Collection Actions` inclui `Evaluate Broken Promise to Pay`, `Write-off Outstanding Balance`, `Update GL Accounts for Write Off` e `Transfer Claim to External Collection Agency`.

## Renegociação x reestruturação
| Dimensão | Renegociação | Reestruturação |
| --- | --- | --- |
| Definição regulatória | Acordo que altera as condições originalmente pactuadas ou substitui o instrumento, conforme Res. CMN 4.966/2021, art. 2º, XX. | Renegociação com concessões significativas por deterioração relevante da qualidade creditícia, que não seriam concedidas sem essa deterioração, conforme art. 2º, XXI. |
| Efeito de risco | Pode ser ajuste contratual sem virar ativo problemático por si só. | É indicativo de ativo problemático, conforme art. 3º, § 2º, II. |
| Mapeamento do autor no BIAN | BQ Modification do domínio de produto, por exemplo `PUT /ConsumerLoan/{id}/Modification/{id}/Update`. | Account Recovery, porque a conta já está em dificuldade e pode envolver modificação e writedown. |
| Mensuração contábil | Renegociação sem reestruturação usa a taxa das condições renegociadas, conforme arts. 22 e 23. | Reestruturação reavalia o valor contábil pela taxa efetiva original, conforme arts. 22 e 23. |

## Recuperação não é só insistir no contato

Account Recovery começa quando a conta passou da cobrança normal e ainda não foi baixada. O YAML v14 tem 17 operações, com BQs Assessment, Planning, Negotiation, Modification e Writedown. O endpoint `PUT /AccountRecovery/{id}/Writedown/{id}/Update` é uma boa lembrança arquitetural: recuperação pode terminar em baixa parcial, não apenas em promessa de pagamento.

Collections, no BIAN, é mais específico do que a palavra em português sugere. A descrição é administrar a recuperação ou liquidação de colateral contra contas problemáticas. As key features incluem Collateral Liquidation e Account/debt factoring. O exemplo `POST /Collections/{id}/CollateralLiquidation/Initiate` mostra o papel certo: garantia, liquidação ou factoring de dívida. Chamar qualquer ligação de cobrança de Collections empobrece o mapa e cria dono errado para ação errada.

A Res. CMN 4.966/2021 fecha a disciplina da baixa. A baixa ocorre quando não for provável recuperar. Os controles sobre o valor baixado precisam existir por no mínimo 5 anos enquanto houver cobrança. E, desde 1º/09/2025, o ativo baixado que for renegociado volta como ativo problemático com provisão de 100%. Essa última frase é onde arquitetura e contabilidade se encontram: o sistema pode até vender uma jornada bonita, mas o ledger precisa continuar contando a verdade.

## Como eu desenho a fronteira de escrita

1. **1. Separe visão de comando**: Bank Portfolio Administration, Bank Portfolio Analysis e Economic Capital podem alimentar painéis, gatilhos analíticos e priorização. Eles não devem atualizar linha, promessa, reestruturação ou baixa.

2. **2. Escolha o dono pelo estágio da conta**: Customer Billing fatura e lembra. Delinquent Account Handling trata o primeiro controle do atraso. Card Collections trata a cobrança do cartão. Account Recovery trata dificuldade mais profunda. Collections trata colateral e liquidação.

3. **3. Audite a transição, não só o saldo**: Promessa quebrada, transferência para agência externa, writedown e baixa são eventos de controle. Se eles aparecem só como atributo sobrescrito, você perdeu a linha do tempo que o auditor vai pedir.

## Capital, concentração e safra explicam a leitura, não substituem o dono

Capital entra como lente de carteira. A Res. CMN 4.958/2021 define requerimentos mínimos de PR em 8%, Nível I em 6% e Capital Principal em 4,5% do RWA. A norma vigente é a Res. BCB 229/2022 (a Circular 3.644 foi revogada): no crédito padronizado, RWA é a soma de exposição multiplicada pelo Fator de Ponderação de Risco. Para exposição de varejo, pessoa natural ou pessoa jurídica de pequeno porte, não garantida por imóvel, o art. 46 traz FPR de 75%.

Concentração, pela Res. 4.557, art. 21, § 3º, VI, pode aparecer por mesma contraparte, setor, região, tipo de produto ou mesmo mitigador. Isso é útil para priorizar análise, stress e apetite de risco. Não é permissão para um motor de capital alterar o contrato do cliente.

Safra é outro bom exemplo. Como recorte de análise, é prática de mercado. Não li definição normativa de safra. O conceito do BIS mais próximo é seasoning, em CRE36.17. Então eu uso safra para comparar comportamento de grupos de originação, mas não finjo que ela é uma entidade regulatória no BIAN. Arquitetura boa aguenta essa diferença sem inventar domínio.

### Checagem rápida

1. **Pela Res. CMN 4.966, quando uma renegociação vira reestruturação?**
- [x] Quando há concessões significativas por causa da deterioração relevante da qualidade de crédito, _E a reestruturação é indicativo de ativo problemático._
- [ ] Sempre que muda a taxa, _Mudar condição é renegociação; reestruturação pede concessão por deterioração._
- [ ] Só para empresas, _A definição não distingue pessoa física e jurídica._
- [ ] Depois da baixa, _A baixa é outro momento (art. 49)._

2. **No BIAN v14, o Collections é…**
- [x] a recuperação e liquidação de garantias de contas problemáticas, inclusive venda da dívida, _O começo do atraso é do Delinquent Account Handling._
- [ ] toda a cobrança, do primeiro lembrete em diante, _Esse é o erro de tradução mais comum._
- [ ] o cálculo da provisão, _Não existe domínio de provisão na v14._
- [ ] a análise de rentabilidade da carteira, _Isso é do Product Portfolio e do Customer Portfolio._

## Perguntas que evitam erro de desenho

### Onde fica a provisão no mapa?

Não existe Service Domain v14 de provisão. A aula trata baixa, contabilização e ativo problemático como efeitos regulatórios e contábeis, com Financial Accounting lançando quando aplicável.

### Cartão renegociado sempre vira reestruturação?

Não. Renegociação e reestruturação são conceitos diferentes na Res. CMN 4.966/2021. No cartão, a renegociação é assegurada a qualquer momento, desde que juros e encargos não excedam o valor original da dívida, conforme Res. CMN 5.112, art. 2º-C da Res. 4.549.

### Superendividamento entra como domínio BIAN?

Não como domínio próprio nesta aula. A Lei 14.181/2021 define a impossibilidade manifesta de o consumidor pessoa natural de boa-fé pagar dívidas de consumo sem comprometer o mínimo existencial. O Decreto 11.150/2022, com redação do Decreto 11.567/2023, fixa esse mínimo em R$ 600,00 de renda mensal e exclui itens como financiamento imobiliário, operações com garantia real, consignado, antecipação ou cessão de recebíveis, limites não usados de cartão e cheque especial.

## A decisão de arquitetura

A recomendação desta aula é estreita de propósito. Use Bank Portfolio Administration, Bank Portfolio Analysis e Economic Capital para ler a carteira, explicar risco consolidado, priorizar ação e sustentar governança. Use os domínios de produto e seus BQs de Modification para renegociação comum. Use Account Recovery quando a conta já exige tratamento de dificuldade, negociação, modificação ou writedown. Use Collections quando o assunto for colateral, liquidação ou factoring de dívida contra conta problemática.

O erro caro não é chamar uma tela de cobrança pelo nome errado. O erro caro é permitir que várias áreas escrevam o mesmo estado da conta com justificativas diferentes. Aí você perde idempotência, perde trilha de auditoria e, pior, perde a capacidade de explicar por que uma conta saiu de atraso inicial para recuperação, de recuperação para baixa, ou de baixa para renegociação como ativo problemático.

A regra final é simples: leitura ampla, escrita estreita. Carteira mostra o filme inteiro. Cada estágio da conta tem um dono. É assim que o mapa do BIAN deixa de ser poster e vira contrato operacional.

### 24. Regulação, o core de crédito e IA Builder no crédito

_As peças viram sistema com um dono por registro, a regulação vira checklist e a IA apoia sem decidir._

A última aula fecha o crédito pela peça que mais falha em arquitetura: a costura. Proposta, rating, limite, garantia, contrato, carteira e cobrança só viram sistema quando cada registro tem um dono claro, a regulação entra como checklist executável e a IA apoia sem assumir a decisão.

## O fechamento do crédito não é uma tela, é uma cadeia de donos

Depois das aulas sobre linhas, proposta, rating, limites, garantias e recuperação, a pergunta muda. Não é mais “qual domínio representa crédito?”. A pergunta certa é: quem é dono de cada registro quando o crédito atravessa o banco inteiro?

Na leitura do autor, o core de crédito fica mais claro em sete peças. Originação fica com `Customer Offer`, `Customer Product And Service Eligibility` e `Underwriting`. Decisão e modelos ficam com `Customer Credit Rating`, `Credit Risk Models` e `Customer Behavior Models`. Limites ficam com `Credit Facility` e `Customer Position`. Contratos ficam com `Customer Agreement`, `Sales Product Agreement` e os domínios de produto: `Credit Card`, `Consumer Loan`, `Merchandising Loan`, `Mortgage Loan` e `Corporate Loan`.

Garantias ficam com `Party Asset Directory`, `Collateral Allocation Management` e `Collateral Asset Administration`. Cobrança usa `Delinquent Account Handling`, `Card Collections`, `Account Recovery` e `Collections`, sem transformar `Collections` no nome de tudo. Carteira fica com `Bank Portfolio Administration` e `Financial Accounting`.

A vida da Marina e o grupo do Rafael fecham o raciocínio: o limite de R$ 50 mil da Marina e o limite de grupo de R$ 600 mil do Rafael são galhos da mesma árvore, com donos diferentes para decisão, exposição, contrato e acompanhamento.

## Quadro mínimo de regulação que entra no desenho
| Tema | Norma | O que pede para a arquitetura |
| --- | --- | --- |
| SCR | Res. CMN 5.037/2022 | Reporte mensal independentemente do adimplemento e consulta com autorização específica do cliente. |
| Cadastro Positivo | Lei 12.414/2011 com LC 166/2019 | Inclusão automática com direito de saída e revisão de decisão automatizada. |
| Cartão | Res. 4.549/2017, Lei 14.690/2023 art. 28 e Res. CMN 5.112/2023 | Rotativo até a fatura seguinte, teto de juros e encargos no valor original da dívida. |
| Cheque especial | Res. 4.765/2019 | Juros até 8% ao mês e regras de redução e aumento do limite. |
| Consignado | Lei 10.820/2003 com Lei 15.179/2025 e Lei 8.213/1991 art. 115 | Margens de 40% e 45%. |
| CET e portabilidade | Res. CMN 4.881/2020 e Res. CMN 5.057/2022 | Custo total apresentado e capacidade de portar a operação conforme regra aplicável. |
| Recebíveis e garantias | Res. 4.734/2019, Res. BCB 264/2022, Lei 9.514/1997 e Lei 14.711/2023 | Regras para recebíveis, alienação fiduciária e garantias no desenho de vínculo e execução. |
| Risco, capital e grupo | Res. CMN 4.966/2021, Res. 4.557/2017, Res. 4.677/2018, Res. 4.553/2017, Res. CMN 4.950/2021, Res. CMN 4.958/2021 e Res. BCB 229/2022 | Perda esperada, risco de crédito, contrapartes conectadas, grandes exposições, segmentação, conglomerado prudencial e capital. |
| Superendividamento e LGPD | Lei 14.181/2021, Decreto 11.150/2022 e LGPD art. 20 | Mínimo existencial de R$ 600,00 e revisão de decisão automatizada, inclusive perfil de crédito. |

## Norma não vira domínio

Um erro comum é ler uma norma e criar um domínio novo com o nome do produto, da obrigação ou do relatório. No BIAN 14, isso quebra o mapa. Não existe Service Domain v14 de cheque especial, consignado ou provisão. Também não existe `Overdraft Management` ou `Provisioning` como domínio v14. Se o seu mapeamento cria esses nomes, o problema está no método, não no BIAN.

O envio mensal ao SCR fica em `Regulatory Reporting` com o padrão funcional `Administer`. O passo `Register Loan with External Agencies` do cenário 55660, junto com `Information Provider Operation` com o padrão funcional `Operate`, é a leitura do autor mais próxima de “registrar fora”. Já `Regulatory Compliance`, com o padrão funcional `Assess`, confere a ação contra a regulação, incluindo `Confirm Action Complies with Regulations` no cenário 55380.

A regra prática é simples: norma vira checagem em um domínio que já existe ou restrição de implantação. Ela define autorização, evidência, retenção, elegibilidade, trilha de auditoria, explicação ou bloqueio. Ela não autoriza inventar um domínio porque o organograma, o produto ou o regulador usa aquele nome.

## Core de crédito em sete peças, com IA ao lado

O desenho mostra dono do registro, leitura entre peças e IA como apoio revisado por pessoa.

### 👤 Cliente: Pedido e autorização

- Cliente pedido, consentimento e documentos (user)

### 🧭 Crédito: Decisão e exposição

- Originação Customer Offer, Eligibility, Underwriting (compute)
- Decisão e modelos Credit Rating, Risk Models, Behavior Models (compute)
- Limites Credit Facility, Customer Position (data)

### 📄 Contrato e garantia

- Contratos Agreements e produtos de crédito (data)
- Garantias Asset Directory, Allocation, Administration (data)

### 📊 Carteira e cobrança

- Carteira Bank Portfolio Administration, Accounting (data)
- Cobrança Delinquent, Card Collections, Recovery, Collections (compute)

### 🔐 Regulação e IA

- Regulatory Compliance checagem contra norma (security)
- Regulatory Reporting SCR mensal (external)
- IA Builder rascunho, explicação, monitoramento (ai)
- Pessoa e política versionada aprovação e responsabilidade (security)

### Fluxos

- client -> origination: entra com pedido e autorização
- origination -> decision: pede avaliação
- decision -> limits: atualiza exposição aprovada
- limits -> contracts: contrato consome limite
- contracts -> collateral: vincula bem quando houver
- contracts -> portfolio: vira posição em carteira
- portfolio -> collections: sinaliza atraso
- compliance -> origination: confere regra antes da ação
- portfolio -> reporting: envia SCR mensal
- ai -> decision: apoia, não aprova
- ai -> collections: sugere proposta dentro da política
- human -> decision: decide com versão de política

### O registro e o dono

- **Limite global do cliente** → Credit Facility
- **Valor de mercado do bem** → Party Asset Directory
- **Quanto do bem cobre cada contrato** → Collateral Allocation Management
- **Rating do cliente** → Customer Credit Rating
- **Reestruturação com baixa parcial** → Account Recovery
- **Envio mensal ao SCR** → Regulatory Reporting

> **Minha leitura prática:** Na prática, eu não deixo a IA decidir crédito. Ela lê documento, organiza balanço, explica decisão, sugere cobrança dentro da política e aponta sinais para renegociação. A aprovação continua com pessoas, política versionada, trilha de auditoria e atributos proibidos bloqueados no pipeline.

## IA Builder no crédito: útil, mas subordinada

A leitura correta de IA no crédito começa por uma restrição, não por uma demo. Basileia CRE36.33 lembra que modelos de score e outros procedimentos mecânicos usam só um subconjunto da informação disponível, então julgamento e supervisão humana suficientes são necessários para considerar toda informação relevante. A LGPD art. 20 dá ao titular o direito de revisão de decisão automatizada, inclusive perfil de crédito.

No Cadastro Positivo, a Lei 12.414/2011 inclui o art. 5º, VI, sobre revisão de decisão exclusivamente automatizada, e o art. 7º-A, sobre informações proibidas na nota: origem social e étnica, saúde, genética, sexo, convicções políticas, religiosas e filosóficas. Em arquitetura, isso vira lista de atributos proibidos no pipeline, teste automatizado, evidência e bloqueio.

Os bons usos de IA são de apoio. Ler documento e balanço para alimentar `Financial Statement Assessment`. Explicar a decisão em linguagem simples. Apoiar cobrança com proposta dentro da política. Monitorar sinais em `Customer Financial Insights`, novo na v14, para detectar mudanças na situação financeira que podem pedir renegociação.

O laço da parte 2 vale inteiro: busque nas fichas v14 com versão fixada, gere proposta com trecho da ficha, valide contra lista fechada, rejeite nome inventado, cheque grounding e só então leve para decisão humana.

## Antipadrões que esta aula deve eliminar

- **Limite calculado em vários lugares:** duas regras para o mesmo limite viram divergência operacional, principalmente em grupo econômico e conglomerado.
- **Domínio de produto decidindo crédito:** `Credit Card` ou `Consumer Loan` pode operar produto, mas a decisão de crédito precisa de dono próprio.
- **Valor da garantia copiado em cada contrato:** cópia envelhece mal, quebra auditoria e confunde execução.
- **Collections como nome de toda cobrança:** a cobrança tem atraso, cobrança de cartão, recuperação e execução de garantia, cada etapa com seu dono.
- **Provisão escondida no sistema de produto:** perda esperada e contabilidade precisam aparecer no desenho, mesmo sem inventar domínio de provisão.
- **Decisão sem versão do modelo e da política:** sem versão, você não explica por que aprovou, negou ou mudou o limite.

## Checklist de segunda-feira para desenhar crédito

1. **Nomeie o dono do limite**: Defina onde nasce, muda e expira a exposição. Se duas peças calculam o mesmo limite, pare e corrija antes de discutir tela.

2. **Nomeie o dono do bem**: Separe cadastro do bem, alocação da garantia e administração da garantia. Contrato referencia, não copia a verdade inteira.

3. **Nomeie quem decide e com qual versão**: Guarde versão de modelo, política, atributos usados, atributos bloqueados e explicação. Isso é arquitetura, não documentação posterior.

4. **Passe a norma por `Regulatory Compliance`**: A norma entra como checagem, evidência ou restrição. Ela não vira domínio novo porque o nome parece importante.

### IA no crédito

1. **Qual uso de IA no crédito respeita CRE36.33, a LGPD e a Lei 12.414?**
- [x] Ler o balanço do Café Aurora e explicar a decisão, com um analista decidindo pela política versionada, _Apoio com julgamento e supervisão humana, e decisão revisável._
- [ ] Aprovar e desembolsar sozinha para ganhar tempo, _Decisão e responsabilidade ficam com pessoas._
- [ ] Usar saúde e religião para melhorar a nota, _O art. 7º-A da Lei 12.414 proíbe._
- [ ] Criar o domínio 'Provisioning' para o mapa, _Não existe na v14; o validador rejeita._

## Fechamento do curso

### Qual é a principal pergunta depois de aprender o mapa?

Pergunte quem é dono do registro. O mapa só ajuda quando ele reduz ambiguidade operacional, especialmente em limite, garantia, contrato, carteira e cobrança.

### A IA pode aprovar crédito se estiver bem avaliada?

Nesta leitura, não. Ela apoia leitura, explicação, monitoramento e proposta dentro da política. Decisão e responsabilidade ficam com pessoas e com a política versionada.

### O que levar para o exame final?

Leve três perguntas: quem é o dono do limite? quem é o dono do bem? quem decide e com qual versão? Elas resumem a parte 3 e servem para ler qualquer desenho de crédito.

### Recapitulação da parte 3

- **Linhas**: Cada linha tem domínio de produto; cheque especial e consignado não têm domínio próprio.
- **Decisão e risco**: Underwriting decide e consulta; rating, modelo e provisão são coisas diferentes.
- **Limites e grupo**: Credit Facility monta a árvore; grupo é do cliente, conglomerado é do banco.
- **Garantias e cobrança**: Bem, alocação e administração têm donos diferentes; Collections é liquidar garantia, não toda a cobrança.

## O curso termina no exame, mas o método começa no desenho real

BIAN não substitui arquitetura. Ele dá vocabulário para discutir fronteira, responsabilidade e contrato sem transformar cada produto em um sistema isolado. No crédito, isso vale dobrado, porque a mesma decisão toca cliente, SCR, Cadastro Positivo, LGPD, limite, garantia, carteira, cobrança, perda esperada, capital e explicação.

Se você levar uma coisa desta parte 3, leve a árvore. O produto é um galho. O contrato é outro. A garantia é outro. O limite de cliente, grupo econômico e conglomerado precisa aparecer como estrutura, não como planilha escondida ou regra duplicada. Quando essa árvore fica explícita, a conversa com risco, jurídico, contabilidade, operações e tecnologia fica menos teatral e mais verificável.

O exame final na página do curso cobra esse tipo de leitura: dado um caso, encontre o dono do registro, não o nome mais bonito. Dado um uso de IA, separe apoio de decisão. Dada uma norma, diga se ela vira checagem, evidência ou restrição de implantação. O certificado vale mais quando você consegue aplicar isso na segunda-feira seguinte, em um desenho que alguém vai operar às 2h da manhã.

## Exame final

### Exame final: BIAN na prática

1. **Na versão 14 do BIAN, o que aconteceu com o Service Domain Payment Execution?**
- [ ] Continua registrado sem mudanças
- [ ] Foi renomeado para Payment Rail
- [ ] Foi fundido ao Current Account
- [ ] Foi marcado como obsoleto, com Payment Settlement como substituto anunciado

2. **Qual é o padrão funcional do Current Account?**
- [ ] Process
- [ ] Transact
- [ ] Fulfill
- [ ] Track

3. **O que é o Control Record de um Service Domain?**
- [ ] O registro que o domínio controla, resultado de padrão funcional aplicado a um tipo de ativo
- [ ] O contrato OpenAPI publicado pelo BIAN
- [ ] A tabela principal do banco de dados do sistema
- [ ] O log de auditoria exigido pelo regulador

4. **Quais action terms apenas leem, sem alterar estado?**
- [ ] Request e Exchange
- [ ] Retrieve e Evaluate
- [ ] Notify e Feedback
- [ ] Retrieve e Notify

5. **No Pix, qual Service Domain da v14 corresponde à resolução da chave consultada no DICT?**
- [ ] Payment Orchestration
- [ ] Payee Management
- [ ] Party Reference Data Directory
- [ ] Customer Consent

6. **Segundo o Banco Central, como o SPI liquida os pagamentos?**
- [ ] Por liquidação bruta em tempo real, transação por transação, sem saldo negativo nas Contas PI
- [ ] Em lotes compensados ao fim do dia
- [ ] Por liquidação diferida em D+1
- [ ] Pela bandeira do cartão

7. **Na Semantic API do BIAN, /CurrentAccount/{id}/DebitandCredit/{id}/Execute é:**
- [ ] Uma consulta, que usa GET
- [ ] Uma operação sobre o Behavior Qualifier DebitandCredit, que nos YAMLs v14 usa PUT
- [ ] Um evento assíncrono, sem método HTTP
- [ ] A criação de uma conta, que usa POST

8. **Qual afirmação descreve melhor a Resolução CMN 4.893 em outubro de 2026?**
- [ ] Está em vigor, com alterações posteriores, e no mapa vira restrição de implantação
- [ ] Foi revogada em 2025
- [ ] Criou o Service Domain de nuvem do BIAN
- [ ] Trata apenas do Pix

9. **Um modelo de linguagem sugeriu 'Credit Card Position Keeping' para um sistema de cartões. O que fazer?**
- [ ] Criar um domínio próprio com esse nome
- [ ] Rejeitar no validador, porque na v14 o domínio se chama Card Transaction Tracking
- [ ] Aceitar, porque o nome parece oficial
- [ ] Pedir ao modelo que confirme

10. **Qual é o erro do '340 microsserviços'?**
- [ ] Usar menos serviços do que o BIAN recomenda
- [ ] Tratar cada Service Domain como um serviço obrigatório, trocando um monólito por custo de rede, deploy e plantão
- [ ] Publicar eventos em vez de APIs
- [ ] Ignorar a ISO 20022

11. **O cenário oficial "Handle Request to Open Retail Current Account", publicado na v14, lista a linha de vida Payment Order. O que fazer ao usá-lo?**
- [ ] Trocar por Payment Execution
- [ ] Remover a linha de vida sem substituto
- [ ] Usar Payment Order, porque o cenário é oficial
- [ ] Trocar pelo substituto anunciado, Payment Confirmation, e registrar a troca

12. **Pela Resolução BCB 443/2024, um boleto de R$ 300.000,00 deve ser liquidado como?**
- [ ] Só por compensação multilateral no dia seguinte
- [ ] Pelo STR, no mesmo dia, com envio à liquidação em até 60 minutos após o pagamento
- [ ] A critério do pagador
- [ ] Pelo SPI, em tempo real

13. **Na Semantic API v14 do Consumer Loan, como aparece o desembolso?**
- [ ] Como Grant
- [ ] Não aparece
- [ ] Como Initiate e Execute no próprio Consumer Loan
- [ ] Só como Retrieve; quem inicia e executa é o Disbursement

14. **Qual afirmação sobre o Suitability Checking da v14 é correta?**
- [ ] A ficha fala em confirmar que as contrapartes são adequadas a uma operação de mercado
- [ ] Foi renomeado para Customer Consent
- [ ] Está obsoleto na v14
- [ ] A ficha descreve a avaliação do perfil de risco do investidor exigida pela CVM

15. **Pela Circular BCB 3.978, o que é correto sobre a análise de operações suspeitas?**
- [ ] Só se aplica a operações em espécie
- [ ] Tem até 45 dias a partir da seleção, é formalizada em dossiê e não pode ser terceirizada
- [ ] Pode ser feita por terceiros no exterior
- [ ] Deve ser comunicada ao Coaf em 45 dias úteis após a decisão

16. **No caso fictício da Trilha, por que o Pix é o último corte do monólito?**
- [ ] Porque a Lei 12.865 exige
- [ ] Porque o BIAN proíbe separar o Payment Rail
- [ ] Porque o Pix não tem domínio no BIAN
- [ ] Porque é o fluxo de 24 horas que menos tolera experimento, e os cortes anteriores dão eventos e donos estáveis

17. **Onde fica o cheque especial no BIAN v14?**
- [ ] No Service Domain Overdraft
- [ ] No Consumer Loan
- [ ] Não há domínio próprio: é limite em atributos do Current Account e uso típico de Credit Facility
- [ ] No Credit Card

18. **Pela Res. CMN 4.966, um contrato da Marina vai para o terceiro estágio. O que acontece com os outros instrumentos dela?**
- [ ] São baixados para prejuízo
- [ ] Vão para o segundo estágio
- [ ] Vão todos para o terceiro estágio
- [ ] Continuam onde estavam

19. **Segundo a ficha v14 do Credit Facility, o que é o overall Credit Limit?**
- [ ] O limite do cartão de crédito
- [ ] O limite regulatório de 25% do Nível I
- [ ] O máximo interno de exposição que o banco aceita com o cliente, que pode cobrir clientes de um mesmo grupo
- [ ] A margem consignável

20. **O Café Aurora Centro (fictício) é franquia da Rede Aurora, que o Rafael não controla. Para a Res. 4.677, eles são um único cliente?**
- [ ] Sim, porque usam a mesma marca
- [ ] Sim, toda franquia é do grupo da franqueadora
- [ ] Nunca, a regra não vale para pequenas empresas
- [ ] Não por ser franquia; só se houver controle ou dependência econômica, analisada e documentada

21. **O que é o Service Domain Collections na v14?**
- [ ] O envio ao SCR
- [ ] O cálculo da provisão
- [ ] Toda a cobrança, do primeiro lembrete em diante
- [ ] A recuperação e liquidação de garantias de contas problemáticas, inclusive venda da dívida

22. **Pela Res. CMN 4.966, o que diferencia reestruturação de renegociação?**
- [ ] Renegociação sempre leva à baixa
- [ ] Reestruturação é renegociação com concessões significativas por deterioração relevante da qualidade de crédito, e é indicativo de ativo problemático
- [ ] Reestruturação só vale para empresas
- [ ] Nada, são sinônimos