Cartão, crédito e cobrança
Quem é dono de uma disputa, de uma decisão de crédito e de um atraso.
5 min de leitura
Assista ao documentário desta parte: Parte 2 · Um banco por dentro (~68 min)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
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?
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 · solicita crédito
- Customer Offer · orquestra a oferta
- Underwriting · Evaluate e Grant
- Customer Position · posição do cliente
- Customer Credit Rating · classificação de crédito
- Fraud Evaluation · avalia fraude
- Credit Risk Models · modelos de risco
- Regulatory Compliance · avalia conformidade
- Consumer Loan · contrato e Repayment
- Disbursement · Initiate e Execute
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, view54728, 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.
- 1Customer Case abre o caso de conta em dificuldade
- 2Collections cuida da recuperação
- 3Correspondence envia o lembrete
- 4Delinquent Account Handling define a estratégia
- 5Customer Billing sinaliza a parcela não paga
- 6Open Item Management abre o item em aberto
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.