Bellacosa Mainframe e o sistema de cartões

☕ Um Café no Bellacosa Mainframe

🕵️ The Mentalist no Mainframe — O Caso dos R$ 100 que Atravessaram um Sistema de Cartões

Compra → captura → autorização → resposta → clearing → settlement → reconciliação

Imagine Patrick Jane entrando em um grande banco.

Nada de CBI. Nada de assassinato. Nenhuma fita amarela isolando a cena do crime.

Desta vez há uma War Room.

Nas paredes, enormes monitores exibem gráficos de CICS, filas de mensagens, utilização de CPU, tempos de resposta, quantidade de transações aprovadas e recusadas.

Analistas observam SDSF.

Programadores procuram mensagens nos logs.

DBAs verificam Db2.

Especialistas de infraestrutura garantem:

— O mainframe está normal.

O pessoal de redes responde:

— A comunicação está normal.

O suporte de cartões diz:

— Temos clientes reclamando.

No centro da confusão existe apenas uma transação de R$ 100.

Patrick Jane olha para o quadro durante alguns segundos.

Pega uma xícara de café.

E pergunta:

— Vocês estão procurando R$ 100. Eu quero saber a história desses R$ 100.

Silêncio.

Bem-vindo ao mundo de processamento de cartões.

---

🕵️ 1. O crime aparentemente perfeito

João entra no Café Bellacosa.

Pede alguma coisa.

Valor:

R$ 100.

Encosta o cartão na maquininha.

A tela apresenta:

PROCESSANDO...

Poucos segundos depois:

APROVADO.

Para João, terminou.

Para o comerciante, aparentemente terminou.

Para quem está começando em mainframe, talvez também pareça que terminou.

Mas para Patrick Jane a investigação acabou de começar.

Porque aquela pequena palavra — APROVADO — esconde uma infraestrutura gigantesca.

Por trás dela encontramos:

• cardholder;

• merchant;

• POS;

• acquirer;

• scheme/network;

• issuer;

• cadastro;

• conta de cartão;

• produto;

• plafond;

• autorização;

• risco;

• tarifas;

• clearing;

• settlement;

• billing;

• cobrança;

• contabilidade;

• chargeback;

• reconciliação.

E ainda temos CICS, COBOL, Db2, VSAM, MQ, batch, JCL, logs, auditoria e diversos sistemas distribuídos conversando com o ambiente bancário.

O primeiro ensinamento de Jane seria:

Nunca confunda aquilo que o cliente vê com aquilo que realmente aconteceu nos sistemas.

---

💳 2. Conhecendo os suspeitos

Antes de investigar qualquer transação precisamos saber quem estava na sala.

Cardholder

É o portador do cartão.

No nosso caso:

João.

Merchant

É o estabelecimento comercial.

Café Bellacosa.

Acquirer

É a instituição adquirente que mantém o relacionamento de aceitação com o estabelecimento e encaminha a transação para o ecossistema apropriado.

Scheme / Network

É a rede/bandeira que estabelece regras e permite a interoperabilidade entre participantes.

Issuer

É o emissor do cartão.

É no lado do issuer que encontramos boa parte da inteligência necessária para decidir:

“Posso autorizar esta compra?”

O fluxo simplificado fica:

JOÃO
 │
 ▼
CAFÉ BELLACOSA
 │
 ▼
MAQUININHA / POS
 │
 ▼
ACQUIRER
 │
 ▼
SCHEME / NETWORK
 │
 ▼
ISSUER

Só que isso ainda é o desenho visto de helicóptero.

Patrick Jane quer entrar no prédio.

---

🧩 3. Antes do cartão existe o cliente

O banco conhece João antes de conhecer aquela compra.

Existe um universo de cadastro:

CUSTOMER
 │
 ├── identificação
 ├── documentos
 ├── endereço
 ├── contatos
 ├── status
 ├── relacionamento
 └── informações cadastrais

Depois temos a conta de cartão.

E depois os cartões associados.

Uma das primeiras pegadinhas para o iniciante é imaginar:

CLIENTE = CARTÃO

Não.

Podemos ter:

CUSTOMER
   │
   ├── CARD ACCOUNT A
   │       ├── CARD 1
   │       └── ADDITIONAL CARD
   │
   └── CARD ACCOUNT B
           └── CARD 2

O plástico pode vencer.

O cartão pode ser substituído.

O cliente continua existindo.

A conta pode continuar existindo.

Portanto:

CUSTOMER ≠ CARD ACCOUNT ≠ CARD

Esse relacionamento é fundamental.

---

🏷️ 4. O sistema de produtos entra na investigação

Jane encontra algo interessante no cadastro:

PRODUCT-ID = 003

Ele pergunta:

— O que significa 003?

Alguém responde:

— Bellacard Platinum.

A partir daqui descobrimos outra camada.

Um cartão não é simplesmente “um cartão de crédito”.

Ele pertence a determinado produto.

Imagine:

001 BELLACARD CLASSIC
002 BELLACARD GOLD
003 BELLACARD PLATINUM
004 BELLACARD CORPORATE
005 BELLACARD VIRTUAL

Cada produto pode possuir parâmetros e características diferentes.

PRODUCT
 │
 ├── Network
 ├── Currency
 ├── Billing Rules
 ├── Credit Rules
 ├── Transaction Rules
 ├── Fee Plan
 ├── Interest Rules
 ├── Rewards
 ├── Risk Parameters
 └── Channel Rules

E aqui aparece uma importante filosofia de sistemas financeiros.

Não queremos escrever um COBOL diferente para cada cartão.

Queremos separar:

código

de

política de negócio.

O programa sabe calcular.

O produto e seus parâmetros dizem o que calcular e quais regras aplicar.

---

💰 5. Plafond — quanto João realmente pode gastar?

Agora chegamos ao limite de crédito, também chamado em diversos contextos de plafond.

Imagine:

PLAFOND TOTAL       R$ 10.000
UTILIZADO           R$  3.000
PENDENTE            R$    500
DISPONÍVEL          R$  6.500

João deseja gastar:

R$ 100

Parece simples.

Mas Jane desconfia de coisas simples.

Porque limite disponível pode depender de muito mais que:

LIMITE - COMPRAS

Podem existir:

• autorizações pendentes;

• parcelamentos;

• reservas;

• bloqueios;

• limites temporários;

• limites específicos por operação;

• regras internacionais;

• saques;

• operações ainda não apresentadas no clearing;

• ajustes e pagamentos.

Portanto, antes de responder APROVADO, o issuer precisa consultar o contexto financeiro correto.

---

🧠 6. A sala de interrogatório: Authorization

A mensagem finalmente chega ao autorizador.

No universo mainframe poderíamos imaginar conceitualmente:

NETWORK
   │
   ▼
GATEWAY
   │
   ▼
CICS
   │
   ▼
AUTHORIZATION
   │
   ├── CARD STATUS
   ├── ACCOUNT STATUS
   ├── PRODUCT RULES
   ├── AVAILABLE CREDIT
   ├── RISK/FRAUD
   ├── MERCHANT INFORMATION
   └── SECURITY CONTROLS

Começa o interrogatório.

O cartão existe?

Sim.

Está ativo?

Sim.

Está vencido?

Não.

Está bloqueado?

Não.

A conta está habilitada?

Sim.

O produto permite essa operação?

Sim.

Existe plafond?

Sim.

Os controles de risco permitem continuar?

Sim.

Então:

APPROVED

Pode surgir também um:

AUTHORIZATION CODE

que ajuda a identificar aquela autorização.

Mas aqui está uma das maiores lições deste artigo:

AUTORIZAÇÃO NÃO É LIQUIDAÇÃO.

A aprovação não significa simplesmente:

“R$ 100 já chegaram à conta bancária do Café Bellacosa.”

Significa que aquela solicitação percorreu o processo de autorização e recebeu uma resposta positiva.

---

🚫 7. Decline — quando Jane diz não

Se alguma regra impedir a autorização, teremos um decline.

Por exemplo:

AVAILABLE CREDIT = R$ 80
PURCHASE         = R$100

Resultado:

DECLINED

Mas insuficiência de limite é apenas uma possibilidade.

Podem existir recusas relacionadas a:

• status do cartão;

• vencimento;

• bloqueio;

• restrições;

• produto;

• risco;

• tipo de operação;

• condições da conta.

A grande descoberta aqui é que uma transação não possui apenas dois estados:

EXISTE
NÃO EXISTE

Ela possui um ciclo de vida.

RECEIVED
   ↓
VALIDATING
   ↓
AUTHORIZED
   ↓
CLEARED
   ↓
SETTLED
   ↓
RECONCILED

E pode desviar:

DECLINED
REVERSED
PENDING
DISPUTED
CHARGEBACK

O cartão é praticamente uma gigantesca máquina de estados financeiros.

---

⏱️ 8. O mistério do timeout

João faz a compra.

O issuer recebe a solicitação.

Processa.

Autoriza.

Envia a resposta.

Mas a resposta se perde pelo caminho.

POS
 │
 ▼
ACQUIRER
 │
 ▼
NETWORK
 │
 ▼
ISSUER
 │
 ├── APPROVED
 │
 X
 X comunicação interrompida
 X

A maquininha pode concluir:

TIMEOUT.

Agora temos um problema fascinante.

Para um sistema:

AUTHORIZED

Para outro:

TIMEOUT

Os sistemas possuem percepções diferentes do mesmo acontecimento.

E isso nos leva a uma das regras de ouro da investigação:

Estado técnico e estado de negócio não são necessariamente a mesma coisa.

---

🔄 9. Reversal — desfazendo uma autorização

Se uma autorização precisa ser desfeita, podemos encontrar um reversal.

Conceitualmente:

AUTHORIZATION
     │
     ▼
RESERVE / AFFECT AVAILABLE CREDIT

Depois:

REVERSAL
     │
     ▼
RELEASE / ADJUST

Por isso o investigador não pode parar quando encontra:

APPROVED

Precisa continuar:

APPROVED
   │
   ├── REVERSAL?
   │
   ├── CLEARING?
   │
   └── WHAT HAPPENED NEXT?

Jane nunca encerra a investigação na primeira evidência.

---

👯 10. O caso dos gêmeos: Duplicate Transaction

Agora encontramos:

10:32:01 R$100
10:32:03 R$100

Temos duas compras?

Ou uma transação retransmitida?

Essa é a essência do problema de duplicate transaction.

Para descobrir precisamos correlacionar informações como:

merchant
terminal
amount
timestamps
transaction identifiers
trace/reference numbers
authorization information

dependendo do protocolo e arquitetura envolvidos.

O iniciante procura:

“R$100.”

O especialista pergunta:

“Qual é a identidade dessa transação?”

Essa pergunta vai nos acompanhar até o fim.

---

📡 11. A maquininha também é um computador administrado

Jane pega a POS do Café Bellacosa.

Ela parece pequena.

Mas possui identidade e configuração.

Conceitualmente podemos encontrar:

TERMINAL-ID
MERCHANT-ID
STORE-ID
SERIAL
MODEL
APPLICATION VERSION
CONFIGURATION
CAPABILITIES
NETWORK PARAMETERS
SECURITY CONTEXT

Ela é um endpoint transacional.

E alguém precisa administrar potencialmente milhares ou milhões desses endpoints.

Entra em cena o:

TMS — Terminal Management System

                   MATRIZ
                     │
                     ▼
                    TMS
                     │
       ┌─────────────┼─────────────┐
       │             │             │
 CONFIGURATION    SOFTWARE     PARAMETERS
       │             │             │
       └─────────────┼─────────────┘
                     │
                  NETWORK
                     │
        ┌────────────┼────────────┐
        ▼            ▼            ▼
       POS          POS          POS

---

🏢 12. A conversa entre matriz e maquininhas

Precisamos separar duas conversas.

A primeira é a transação financeira:

CARD
 ↓
POS
 ↓
ACQUIRER
 ↓
NETWORK
 ↓
ISSUER

É online.

O cliente está esperando.

Latência importa muito.

A segunda é administrativa:

TMS
 ↓
POS

Pode envolver, conforme a solução:

• parâmetros;

• perfis;

• configurações;

• versões de aplicação;

• atualizações;

• informações operacionais.

Não devemos confundir:

TRANSACTION PROCESSING

com:

TERMINAL MANAGEMENT.

---

🏪 13. Merchant, loja e terminal

Também precisamos conhecer a hierarquia:

MERCHANT
   │
   ├── STORE 001
   │      ├── POS 001
   │      ├── POS 002
   │      └── POS 003
   │
   └── STORE 002
          ├── POS 004
          └── POS 005

Agora podemos localizar uma transação com muito mais precisão.

Não aconteceu simplesmente no:

Café Bellacosa.

Pode ter ocorrido no:

MERCHANT 8472
STORE    0004
TERMINAL 0009

Para troubleshooting isso é ouro.

---

🧬 14. A árvore de configuração

Administrar cada terminal individualmente seria impraticável.

Uma arquitetura pode trabalhar com hierarquias conceituais como:

GLOBAL
  ↓
COUNTRY
  ↓
ACQUIRER
  ↓
MERCHANT SEGMENT
  ↓
MERCHANT
  ↓
STORE
  ↓
TERMINAL

Uma configuração global pode valer para enorme quantidade de equipamentos.

Mas podem existir exceções.

GLOBAL
CONTACTLESS = YES

MERCHANT 8472
CONTACTLESS = NO

Então a pergunta de Jane muda.

Ele não pergunta:

“Qual é a configuração global?”

Pergunta:

“Qual era a configuração efetiva desse terminal?”

---

🔐 15. Segurança — não confie simplesmente em quem bate à porta

A POS também precisa participar de uma arquitetura segura.

O ecossistema de pagamentos utiliza diversos mecanismos e padrões envolvendo conceitos como:

EMV
HSM
KEY MANAGEMENT
CRYPTOGRAPHIC KEYS
CERTIFICATES
PIN SECURITY
MESSAGE INTEGRITY
PCI CONTROLS

A implementação exata depende do ambiente.

Mas o princípio é simples:

Uma maquininha não deveria simplesmente anunciar uma identidade e receber confiança automaticamente.

Identidade, autenticidade, integridade e proteção do material criptográfico são fundamentais.

---

🏷️ 16. O outro produto que esquecemos

Existe o produto do cardholder.

Mas também existe o lado comercial do merchant.

O adquirente possui relacionamento contratual com o estabelecimento.

MERCHANT
   │
   ├── CONTRACT
   ├── MCC
   ├── SETTLEMENT RULE
   ├── PRICING PLAN
   ├── BANK ACCOUNT
   └── TERMINALS

Portanto temos dois universos:

ISSUER                       ACQUIRER
   │                            │
CARD PRODUCT              MERCHANT PRODUCT
   │                            │
CARDHOLDER                    MERCHANT

Isso explica por que estudar cartões olhando apenas para o issuer deixa metade do mapa em branco.

---

🏪 17. MCC — que tipo de estabelecimento é esse?

O merchant possui classificação de atividade no ecossistema, incluindo o Merchant Category Code — MCC.

Essa informação pode participar de diferentes regras de:

• autorização;

• risco;

• rewards;

• relatórios;

• políticas comerciais;

• regras da rede.

Imagine um programa de pontos:

RESTAURANT → 2X
GENERAL    → 1X

Aquela pequena classificação passa a produzir consequências em outros sistemas.

Mais uma pista para Jane.

---

💰 18. O misterioso mundo das tarifas

Agora aparece na fatura:

R$12

Cliente pergunta:

— O que é isso?

Resposta ruim:

— Tarifa.

Patrick Jane imediatamente:

— Qual tarifa? Gerada por qual evento? Segundo qual produto? Sob qual regra? Em qual vigência?

Essa é a investigação correta.

Um sistema de tarifas pode possuir algo como:

FEE-ID
DESCRIPTION
PRODUCT
EVENT
CALCULATION METHOD
VALUE
VALID-FROM
VALID-TO
STATUS

Podemos ter eventos como:

ANNUAL_FEE
CASH_ADVANCE
LATE_PAYMENT
CARD_REPLACEMENT
SERVICE

conforme contrato, produto e regras aplicáveis.

---

🧮 19. O Fee Engine

Podemos imaginar:

BUSINESS EVENT
      │
      ▼
   FEE ENGINE
      │
 ┌────┼─────┐
 │    │     │
PRODUCT CUSTOMER CONTRACT
 │    │     │
 └────┼─────┘
      │
    RULE
      │
      ▼
 CALCULATED FEE

Uma tarifa pode ser fixa:

R$12

percentual:

2%

por faixa:

0–1000
1001–5000
>5000

ou condicionada:

IF CUSTOMER-SEGMENT = X
    FEE = 0

Aqui fica clara outra diferença:

regra comercial não deveria ser confundida com lógica fixa enterrada no programa.

---

💵 20. E quanto o merchant paga?

O estabelecimento também possui seu universo econômico.

No acquiring podemos encontrar conceitos como:

• MDR;

• serviços contratados;

• aluguel/serviços de terminal;

• condições de recebimento;

• antecipação de recebíveis;

• outros componentes comerciais.

No ecossistema existe também interchange, conforme as regras do arranjo.

É importante não confundir:

MDR ≠ INTERCHANGE

E também não concluir que tudo aquilo que o merchant paga pertence ao issuer.

A compra de R$100 possui uma economia inteira escondida por trás dela.

---

📦 21. Clearing — “a compra voltou”

Algum tempo depois da autorização aparecem informações de clearing.

O iniciante pergunta:

— Mas ela já não tinha sido aprovada?

Sim.

Só que:

AUTHORIZATION

e:

CLEARING

não são a mesma coisa.

Uma maneira didática de pensar é:

Authorization:

“Posso permitir esta operação?”

Clearing:

“Aqui está a transação apresentada para o processamento financeiro correspondente.”

E podem existir situações nas quais valores apresentados e autorizados não sejam simplesmente idênticos.

Hotel é um bom exemplo conceitual:

AUTHORIZATION
R$1.000

FINAL / PRESENTED AMOUNT
R$870

Logo:

AUTHORIZATION ≠ CLEARING

embora os dois façam parte da história da mesma operação.

---

💰 22. Settlement — agora estamos falando de posições financeiras

Depois chegamos ao settlement.

É aqui que tratamos da liquidação das posições financeiras entre participantes conforme os processos e regras da rede.

Isso destrói outra imagem simplista:

“A mensagem de autorização carregou R$100 de um banco para outro.”

Não.

A autorização é uma decisão online.

Clearing e settlement fazem parte de processos posteriores relacionados ao processamento e liquidação financeira.

A mesma transação possui várias representações durante sua vida.

---

🧾 23. Billing — agora João precisa pagar

A transação apresentada/postada passa a compor o universo financeiro da conta de cartão conforme o produto.

CARD ACCOUNT
    │
    ├── PURCHASES
    ├── INSTALLMENTS
    ├── INTEREST
    ├── FEES
    ├── CREDITS
    └── ADJUSTMENTS

Chega o fechamento.

Conceitualmente:

SALDO ANTERIOR
+ COMPRAS
+ JUROS
+ TARIFAS
- PAGAMENTOS
- CRÉDITOS
----------------
= FATURA

Agora o sistema de cartão precisa conversar fortemente com o restante do ambiente bancário.

---

🏦 24. A ponte com o banco

João paga sua fatura.

Esse pagamento pode entrar através de diferentes canais e sistemas.

BANKING CHANNEL
      │
      ▼
PAYMENT PROCESSING
      │
      ▼
CARD ACCOUNT
      │
      ├── REDUCE BALANCE
      └── RESTORE / ADJUST AVAILABLE CREDIT

Perceba como a arquitetura cresceu.

Começamos com:

POS → AUTORIZADOR

Agora temos:

CUSTOMER
CARD
ACCOUNT
PRODUCT
LIMIT
AUTHORIZATION
CLEARING
BILLING
PAYMENT
BANKING
ACCOUNTING

O sistema de cartões é uma ponte entre o mundo do pagamento e o mundo bancário.

---

💸 25. Cobrança

E se João não pagar?

Outra porta se abre.

BILL
  │
  ▼
DUE DATE
  │
  ├── PAID
  │
  └── UNPAID
         │
         ▼
     DELINQUENCY
         │
         ▼
     COLLECTION

Agora entram regras de atraso, cobrança, encargos, negociação e tratamento do relacionamento conforme produto, contrato e regulamentação.

A compra de R$100 feita em segundos pode permanecer meses dentro dos sistemas.

---

📚 26. Contabilidade — toda história precisa fechar

Em algum momento, os eventos financeiros relevantes precisam produzir os registros contábeis apropriados.

Conceitualmente:

CARD EVENT
    │
    ▼
BUSINESS EVENT
    │
    ▼
ACCOUNTING INTERFACE
    │
    ▼
ACCOUNTING ENTRIES
    │
    ▼
GENERAL LEDGER

Aqui existe uma fronteira extremamente importante.

O sistema operacional de cartões sabe:

“O que aconteceu com a transação.”

A contabilidade precisa representar:

“Qual é o efeito econômico desse acontecimento.”

É outra visão da mesma realidade.

---

⚖️ 27. Chargeback — o morto voltou

Semanas depois João olha a fatura.

Encontra:

CAFÉ BELLACOSA    R$100

E diz:

— Não reconheço.

A transação que parecia encerrada retorna.

TRANSACTION
    │
    ▼
DISPUTE
    │
    ▼
INVESTIGATION
    │
    ▼
POSSIBLE CHARGEBACK

Dependendo do caso e das regras aplicáveis, existem processos adicionais de contestação, evidências, representação e resolução.

Isso demonstra uma propriedade importantíssima:

O ciclo de vida da transação pode durar muito mais que os segundos da autorização.

---

🧮 28. Reconciliação — finalmente encontramos Patrick Jane

Agora chegamos ao sistema que mais se parece com nosso detetive.

A reconciliação pergunta:

“Todos estão contando a mesma história?”

Imagine:

AUTHORIZATION     1.000
CLEARING            998
SETTLEMENT          998
ACCOUNTING          998

Jane imediatamente pergunta:

— Onde estão as duas?

Ou:

CARD SYSTEM       R$10.000.000
ACCOUNTING        R$ 9.999.900

Diferença:

R$100.

Nosso velho amigo voltou.

---

🕵️ 29. Reconciliação é forense financeira

Ela procura situações como:

AUTH SEM CLEARING
CLEARING SEM AUTH
DUPLICATE CLEARING
VALUE MISMATCH
CURRENCY MISMATCH
SETTLEMENT DIFFERENCE
REVERSAL PENDING
ACCOUNTING MISSING

Por isso gosto de pensar nela como:

forense financeira automatizada.

Não basta saber que existem registros.

Precisamos provar que universos independentes estão coerentes entre si.

---

⏳ 30. A quarta dimensão: tempo

Patrick Jane encontra uma tarifa:

GOLD ANNUAL FEE = R$300

Cliente reclama:

— Meu contrato dizia R$240.

O analista olha a tabela.

R$300.

Caso encerrado?

Jane pergunta:

— Quanto era a tarifa quando o evento aconteceu?

Silêncio.

Consultamos o histórico:

01/01/2024 – 31/12/2025    R$240

01/01/2026 – ...           R$300

A investigação muda completamente.

Em sistemas financeiros não basta perguntar:

Qual é a regra?

Muitas vezes precisamos perguntar:

Qual era a regra naquele instante?

Isso introduz:

VALID-FROM
VALID-TO
VERSION
STATUS
CREATED-AT
CHANGED-AT
APPROVED-BY

---

📡 31. O mesmo vale para a maquininha

Hoje:

POS VERSION = 120

Mas a transação problemática aconteceu ontem.

Ontem:

POS VERSION = 118

Portanto a pergunta:

“Qual é a versão atual?”

pode ser inútil.

Jane pergunta:

“Qual versão estava efetivamente ativa quando ocorreu o problema?”

Isso é troubleshooting de verdade.

---

📜 32. Logs são testemunhas

No mainframe podemos encontrar evidências espalhadas por diferentes tecnologias e componentes:

APPLICATION LOGS
CICS
MQ
Db2
VSAM
SMF
JES/SDSF
NETWORK RECORDS
BATCH REPORTS
AUDIT RECORDS
RECONCILIATION FILES

Um bom sistema deve permitir reconstruir uma narrativa.

Algo como:

10:32:01.003 RECEIVED
10:32:01.017 CARD VALID
10:32:01.025 LIMIT CHECK
10:32:01.041 RISK CHECK
10:32:01.055 APPROVED
10:32:01.061 AUTH CODE GENERATED
10:32:01.074 RESPONSE SENT

Depois:

02:17:43 CLEARING RECEIVED
02:17:44 AUTH MATCHED
02:17:44 ACCOUNT POSTED
02:17:45 ACCOUNTING GENERATED

Não são apenas linhas.

São depoimentos.

---

🧾 33. Auditoria pergunta quem mexeu na cena do crime

Imagine que alguém alterou uma tarifa.

Precisamos saber:

WHO?
WHEN?
OLD VALUE?
NEW VALUE?
WHO APPROVED?
WHEN EFFECTIVE?

Então podemos encontrar estruturas conceituais como:

FEE_CHANGE_AUDIT
────────────────────────
PRODUCT
FEE
OLD_VALUE
NEW_VALUE
REQUESTED_BY
APPROVED_BY
CHANGE_TIMESTAMP
EFFECTIVE_DATE
REFERENCE

A mesma filosofia pode ser aplicada a mudanças críticas em:

PRODUCT
LIMIT RULE
MERCHANT CONTRACT
TERMINAL PROFILE
SETTLEMENT RULE

Sistema financeiro precisa possuir memória.

---

🖥️ 34. E onde entra o mainframe?

Agora finalmente podemos olhar para tecnologias.

Uma arquitetura híbrida conceitual poderia ser:

POS
 │
 ▼
ACQUIRER EDGE
 │
 ▼
NETWORK
 │
══════════════════════════════════
           IBM Z / z/OS
══════════════════════════════════
 │
 ▼
CICS
 │
 ├── AUTHORIZATION
 ├── CARD ACCOUNT
 ├── PRODUCT
 ├── LIMIT
 └── BUSINESS RULES
 │
 ├── Db2
 ├── VSAM
 └── MQ
 │
 ▼
BATCH
 │
 ├── CLEARING
 ├── BILLING
 ├── SETTLEMENT
 ├── ACCOUNTING
 └── RECONCILIATION

Em ambientes reais essas funções podem estar distribuídas entre mainframe, sistemas distribuídos, cloud, gateways, appliances especializados e fornecedores.

A pergunta arquitetural fundamental não é:

“Está tudo no mainframe?”

A pergunta é:

“Quem é o System of Record de cada verdade?”

---

🧠 35. COBOL não é a primeira coisa que eu ensinaria

Se eu tivesse diante de mim vinte programadores COBOL iniciantes destinados a trabalhar em Cards & Payments, eu não começaria ensinando:

IDENTIFICATION DIVISION.

Começaria colocando R$100 sobre a mesa.

E perguntaria:

“O que acontece com este dinheiro quando alguém encosta um cartão numa maquininha?”

Primeiro ensinaríamos o negócio.

Depois:

CUSTOMER
 ↓
CARD
 ↓
PRODUCT
 ↓
PLAFOND
 ↓
MERCHANT
 ↓
POS
 ↓
ACQUIRER
 ↓
NETWORK
 ↓
ISSUER
 ↓
AUTHORIZATION
 ↓
CLEARING
 ↓
SETTLEMENT
 ↓
BILLING
 ↓
ACCOUNTING
 ↓
RECONCILIATION

Só então COBOL começa a fazer sentido.

---

🧰 36. Cada tecnologia finalmente ganha um motivo para existir

O aluno começa a perceber por que encontrará CICS em processamento transacional online.

Entende por que existem milhões de linhas de COBOL implementando regras de negócio.

Percebe o papel de Db2 e VSAM na persistência de diferentes tipos de informação conforme a arquitetura.

Entende como MQ pode participar da integração entre domínios.

Descobre por que JCL e processamento batch continuam extremamente importantes para volumes massivos, interfaces, fechamentos, billing, clearing, settlement, contabilização e reconciliação em determinadas implementações.

E entende finalmente por que logs, traces, auditoria e monitoramento não são burocracia.

São evidências.

---

🚨 37. WAR ROOM — 03:17

E aqui está nosso pequeno easter egg.

Telefone toca.

03:17.

Produção:

— Temos uma divergência de R$100.

O iniciante entra no SDSF.

Procura:

100.00

Encontra 8.743 ocorrências.

Excelente.

Agora temos 8.743 suspeitos.

😂

Patrick Jane toma café.

Pergunta:

— Qual é a identidade da transação?

Encontramos a primeira referência.

Então construímos:

03:16:57 AUTH REQUEST
03:16:58 APPROVED
03:17:01 TIMEOUT
03:17:04 RETRY
03:17:05 SECOND MESSAGE
03:17:07 REVERSAL

Horas depois:

CLEARING      1
SETTLEMENT    1
ACCOUNTING    0

Aha!

O problema nunca foi:

“sumiram R$100.”

O problema era:

o ciclo de vida da transação foi interrompido entre dois domínios que deveriam concordar.

Agora temos uma investigação.

---

🕵️ 38. Outro incidente: 50 mil maquininhas enlouqueceram

Alguns meses depois:

— Determinadas maquininhas deixaram de aceitar um tipo de operação.

War Room.

CICS:

GREEN.

Db2:

GREEN.

CPU:

GREEN.

MQ:

GREEN.

Network:

GREEN.

Issuer:

GREEN.

Todo mundo declara inocência.

Jane pergunta:

— Quando começou?

— Meia-noite.

— O que mudou à meia-noite?

Silêncio.

Descobrimos:

TERMINAL PROFILE
VERSION 118
VALID UNTIL 23:59:59

Uma parte da frota não recebeu ou não ativou adequadamente determinado perfil/configuração.

Resultado:

1.950.000 POS → OK
   50.000 POS → OLD PROFILE

Nenhum COBOL estava errado.

Nenhum CICS estava quebrado.

A máquina estava simplesmente executando a configuração que possuía.

Essa é uma lição magnífica:

Nem todo incidente de negócio é defeito de código.

---

🧩 39. O grande mapa do BELLACARD

Depois de toda nossa investigação, podemos finalmente desenhar o sistema:

                        CUSTOMER
                           │
                       CADASTRO
                           │
                     CARD ACCOUNT
                           │
             ┌─────────────┼──────────────┐
             │             │              │
          PRODUCT       PLAFOND        FEE PLAN
             │             │              │
             └─────────────┼──────────────┘
                           │
                          CARD
                           │
                           ▼
══════════════════════════════════════════════════
                        MERCHANT
                           │
                        CONTRACT
                           │
                      PRICING PLAN
                           │
                          MCC
                           │
                         STORE
                           │
                          POS
                           │
                    TERMINAL PROFILE
                           │
                          TMS
══════════════════════════════════════════════════
                           │
                        PURCHASE
                           │
                           ▼
                       ACQUIRER
                           │
                        NETWORK
                           │
                         ISSUER
                           │
                    AUTHORIZATION
                           │
                  ┌────────┴────────┐
                  │                 │
               DECLINE          APPROVED
                                    │
                               AUTH CODE
                                    │
                               REVERSAL?
                                    │
                                CLEARING
                                    │
                               SETTLEMENT
                                    │
              ┌─────────────────────┼──────────────────┐
              │                     │                  │
           BILLING              ACCOUNTING       RECONCILIATION
              │                     │
           PAYMENT              GENERAL LEDGER
              │
           BANKING
              │
          COLLECTION

             TRANSACTION
                  │
               DISPUTE
                  │
              CHARGEBACK

Agora podemos finalmente dizer:

isso é um ecossistema de cartões.

---

☕ 40. A verdadeira lição de The Mentalist

Patrick Jane não seria um excelente analista de produção porque sabe COBOL.

Provavelmente nem saberia escrever:

PERFORM UNTIL

Ele seria excelente porque sabe formular perguntas.

Quando aparece uma transação problemática, o iniciante pergunta:

“O programa deu erro?”

Jane perguntaria:

“Qual foi a última evidência confiável?”

O iniciante pergunta:

“A compra foi aprovada?”

Jane:

“Foi posteriormente revertida?”

O iniciante:

“Está no clearing?”

Jane:

“Com qual identidade?”

O iniciante:

“A tarifa é R$300.”

Jane:

“Era R$300 na data do evento?”

O iniciante:

“A POS está na versão 120.”

Jane:

“Estava na versão 120 quando aconteceu?”

O iniciante:

“O mainframe está verde.”

Jane:

“E quem disse que o problema está no mainframe?”

Essa mudança de mentalidade é talvez mais importante que decorar qualquer comando.

---

🔎 41. A regra Bellacosa para investigar cartões

Quando receber um incidente, não procure primeiro pelo erro.

Reconstrua a história.

Comece identificando:

WHO
 │
WHAT
 │
WHEN
 │
WHERE
 │
WHICH PRODUCT
 │
WHICH MERCHANT
 │
WHICH TERMINAL
 │
WHICH TRANSACTION
 │
WHICH AUTHORIZATION
 │
WHICH CLEARING RECORD
 │
WHICH SETTLEMENT
 │
WHICH ACCOUNTING EVENT
 │
WHICH VERSION
 │
WHICH RULE

Depois monte a timeline.

Só então mergulhe no código.

Isso evita horas investigando o componente errado.

---

🧠 42. Curiosidade — a mesma compra possui várias identidades

Esse talvez seja um dos conceitos mais importantes para um futuro especialista.

A compra que João conhece como:

“R$100 no Café Bellacosa”

pode aparecer tecnicamente de maneiras diferentes em:

POS
ACQUIRER
NETWORK
ISSUER
AUTHORIZATION
CLEARING
CARD ACCOUNT
SETTLEMENT
ACCOUNTING
RECONCILIATION

O grande trabalho investigativo é construir uma linha ligando essas representações.

Imagine o mural de The Mentalist:

POS REF
   │
   ▼
ACQUIRER REF
   │
   ▼
NETWORK REF
   │
   ▼
AUTHORIZATION
   │
   ▼
CLEARING REF
   │
   ▼
SETTLEMENT
   │
   ▼
ACCOUNTING REF

A linha vermelha entre elas é aquilo que chamamos de correlação.

Sem ela temos logs.

Com ela temos uma história.

---

🏛️ 43. E essa é a beleza escondida do mainframe

Quando alguém diz:

“COBOL é uma tecnologia velha.”

Talvez esteja olhando para o tijolo e ignorando a catedral.

O programa COBOL que verifica um status pode fazer parte de uma cadeia que permite que alguém compre um café às 10h32 numa cidade qualquer.

O CICS que executa uma transação pode estar no caminho entre uma maquininha e uma decisão financeira que precisa acontecer em segundos.

Um batch executado durante a madrugada pode estar processando milhões de registros de clearing.

Um job pode gerar contabilizações.

Outro pode reconciliar universos inteiros.

Uma fila MQ aparentemente insignificante pode representar a ponte entre duas partes críticas dessa história.

Uma tabela Db2 com uma data de vigência errada pode afetar milhares de clientes.

Um profile incorreto pode transformar milhares de maquininhas perfeitamente saudáveis em protagonistas de uma War Room.

E uma única transação de R$100 pode atravessar tudo isso.

---

☕ Epílogo — A última xícara de café

São 05:42.

A War Room finalmente está silenciosa.

O problema das 03:17 foi identificado.

A transação foi reconstruída.

Encontramos autorização.

Encontramos timeout.

Encontramos retry.

Encontramos reversal.

Encontramos clearing.

Encontramos settlement.

Encontramos a ausência da contabilização esperada.

A reconciliação fez exatamente aquilo para que foi criada:

percebeu que duas histórias não terminavam da mesma maneira.

Alguém pergunta a Patrick Jane:

— Como você descobriu?

Ele olha para os enormes monitores.

Depois para as milhares de linhas do log.

E responde:

“Vocês estavam procurando onde o sistema errou. Eu procurei onde os sistemas deixaram de concordar.”

Talvez essa seja uma das melhores definições para troubleshooting em sistemas de cartões.

Não somos apenas programadores COBOL.

Não somos operadores de CICS.

Não somos leitores de dumps.

Somos investigadores de sistemas.

Cada mensagem é uma pista.

Cada timestamp é uma testemunha.

Cada authorization code é uma evidência.

Cada reversal muda a história.

Cada versão possui seu momento.

Cada parâmetro possui sua vigência.

Cada clearing precisa encontrar sua origem.

Cada lançamento contábil precisa possuir uma explicação.

E toda reconciliação possui uma pergunta extremamente simples:

“As histórias fecham?”

Porque em um sistema financeiro podemos até aceitar que uma mensagem demore alguns milissegundos.

Podemos aceitar que um processo atravesse dezenas de sistemas.

Podemos conviver com COBOL escrito antes de alguns de seus atuais mantenedores nascerem.

O que não podemos aceitar é que R$100 desapareçam sem deixar uma história explicável.

E se um dia, às 03:17, alguém telefonar dizendo:

— Bellacosa, sumiram R$100.

Não procure 100.00 no log.

Pegue um café.

Abra o mural.

Descubra quem era o cliente, qual era o cartão, produto, plafond, merchant, loja e terminal.

Descubra a configuração vigente.

Encontre a autorização.

Procure o reversal.

Siga até o clearing.

Atravesse o settlement.

Cheque billing e cobrança quando aplicáveis.

Chegue à contabilidade.

E finalmente pergunte à reconciliação:

“Onde exatamente nossas histórias deixaram de ser iguais?”

Nesse momento você deixou de ser apenas um programador COBOL iniciante.

Você começou a pensar como um verdadeiro analista de sistemas de missão crítica.

Ou, como Patrick Jane provavelmente diria diante do nosso velho IBM Z:

o mainframe quase sempre deixa pistas. O segredo é saber quais perguntas fazer.

☕🕵️‍♂️💳

Bellacosa Mainframe
Onde até uma compra de R$100 pode virar uma investigação de madrugada.