A anatomia do banco e as três perguntas

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?”.

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.

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.

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.