Bellacosa Mainframe e o processamento do cartão de credito

☕ Um Café no Bellacosa Mainframe

💳 BELLACARD — Como seria um sistema de cartões de crédito dentro de um IBM Mainframe?

Do “BIP!” da maquininha ao COBOL, CICS, Db2, MQ, JCL, RACF, criptografia, antifraude, clearing, settlement e bilhões de transações que ninguém percebe.

Imagine a cena.

Você entra numa cafeteria, pede um café, aproxima o cartão da maquininha e...

BIP!

TRANSAÇÃO APROVADA
R$ 17,50

Você guarda o cartão, pega o café e continua a vida.

Talvez tenham se passado dois segundos.

Para o consumidor, acabou.

Para um programador mainframe curioso, porém, aconteceu uma pequena maravilha tecnológica.

Aqueles poucos segundos podem envolver terminal de pagamento, adquirente, rede de cartões, banco emissor, sistemas de autorização, criptografia, verificação do cartão, consulta de limites, regras de segurança, sistemas antifraude, bancos de dados, logs, mensagens entre plataformas e uma resposta que precisa percorrer boa parte desse caminho no sentido contrário.

E ainda não acabou.

Mais tarde haverá processamento financeiro, clearing, settlement, conciliação, lançamento da compra, fechamento da fatura, eventual parcelamento, pagamento, contabilização, estorno, contestação e talvez até um chargeback.

A humilde compra do café abriu uma pequena saga computacional.

E é exatamente por isso que cartões de crédito são um excelente laboratório para entender por que mainframes existem.

Então coloque café na caneca.

Hoje construiremos mentalmente o:

💳 BELLACARD — Credit Card Processing System for z/OS

Não será o projeto real de nenhum banco ou bandeira. Será uma arquitetura didática para entendermos como tecnologias como COBOL, CICS, Db2, MQ, JCL/JES2, RACF, criptografia, SMF, WLM e Parallel Sysplex podem participar de um grande sistema financeiro.

---

🏪 Capítulo 1 — Tudo começa com R$ 100

Imagine uma compra:

CLIENTE:       JOÃO
VALOR:         R$ 100,00
ESTABELECIMENTO: CAFÉ DO MAINFRAME
FORMA:         CARTÃO

O cartão é apresentado.

A maquininha não conhece necessariamente o saldo da conta do cliente.

O estabelecimento também não.

A adquirente não é necessariamente quem concedeu o crédito.

Existe uma cadeia.

Simplificando:

CARDHOLDER
    │
    ▼
MERCHANT
    │
    ▼
ACQUIRER
    │
    ▼
CARD NETWORK
    │
    ▼
ISSUER

Visa e Mastercard, por exemplo, operam redes que conectam os participantes do ecossistema.

O banco emissor é quem conhece o cartão, sua situação, conta relacionada, limite e diversas regras necessárias para decidir se aquela operação pode prosseguir.

Portanto, eventualmente surge uma pergunta:

“Banco, você autoriza esta compra?”

É aí que nosso BELLACARD acorda.

---

📨 Capítulo 2 — Uma mensagem bate à porta

Imagine que recebamos uma representação simplificada da operação:

TRANSACTION TYPE : PURCHASE
CARD TOKEN        : 987654321
AMOUNT            : 100.00
CURRENCY          : BRL
MERCHANT ID       : 785932
MCC               : 5812
COUNTRY            : BRA
ENTRY MODE         : CONTACTLESS
DATE               : 20260914
TIME               : 031700

Sim.

03:17.

Quem acompanha o Bellacosa Mainframe sabe que esse horário nunca aparece por acidente.

😏

Nosso primeiro easter egg já foi registrado.

Em sistemas reais, mensagens de cartões podem utilizar padrões e protocolos próprios do setor, incluindo famílias baseadas em ISO 8583, além de APIs e formatos modernos dependendo da integração.

Para nosso iniciante COBOL, entretanto, vamos imaginar simplesmente um registro chegando ao mainframe.

---

🖥️ Capítulo 3 — CICS, atenda a porta!

Dentro do z/OS poderíamos possuir uma transação CICS:

AUTH

Sua missão:

processar uma solicitação de autorização.

Conceitualmente:

REQUEST
   │
   ▼
 CICS
   │
   ▼
AUTHORIZATION PROGRAM
   │
   ├── VALIDATE CARD
   ├── CHECK STATUS
   ├── CHECK LIMIT
   ├── CHECK RULES
   ├── CHECK RISK
   │
   ▼
APPROVE / DECLINE

Um pseudocódigo COBOL extremamente simplificado poderia parecer:

       PROCEDURE DIVISION.

           PERFORM VALIDATE-REQUEST
           PERFORM READ-CARD
           PERFORM CHECK-CARD-STATUS
           PERFORM CHECK-AVAILABLE-LIMIT
           PERFORM CHECK-RISK

           IF WS-AUTHORIZED
               PERFORM CREATE-AUTHORIZATION
               PERFORM RESERVE-LIMIT
               MOVE '00' TO WS-RESPONSE-CODE
           ELSE
               MOVE '05' TO WS-RESPONSE-CODE
           END-IF.

Não copie isso para instalar amanhã no banco. 😁

Estamos construindo um modelo didático.

O importante é compreender o fluxo.

---

💳 Capítulo 4 — O cartão existe?

Nossa primeira pergunta parece ridícula:

O cartão existe?

Mas sistemas robustos começam validando o básico.

Podemos possuir algo conceitualmente semelhante a:

CARD
---------------------------
CARD_ID
ACCOUNT_ID
CARD_TOKEN
STATUS
EXPIRATION_DATE
PRODUCT_CODE
BLOCK_CODE

O programa consulta:

SELECT STATUS,
       ACCOUNT_ID,
       EXPIRATION_DATE
FROM CARD
WHERE CARD_TOKEN = :WS-CARD-TOKEN

E descobre:

STATUS = ACTIVE

Ótimo.

Mas poderia encontrar:

BLOCKED
CANCELLED
EXPIRED
LOST
STOLEN

Nesse caso, dependendo das regras:

DECLINED

Observe algo importante para quem está aprendendo COBOL.

O programa não está simplesmente “fazendo contas”.

Ele está implementando regras de negócio.

Essa é uma das essências do COBOL empresarial.

---

🏦 Capítulo 5 — A conta e o limite

Encontramos a conta:

ACCOUNT_ID       = 100238
CREDIT_LIMIT     = 10000.00
AVAILABLE_LIMIT  = 5800.00
CURRENT_BALANCE  = 3400.00
PENDING_AUTH     = 800.00

A compra solicitada é:

100.00

Temos limite.

Mas cuidado.

Não deveríamos simplesmente fazer:

SUBTRACT 100 FROM AVAILABLE-LIMIT.

Por quê?

Porque provavelmente existem milhares de transações concorrentes.

Imagine duas compras quase simultâneas.

AVAILABLE LIMIT = R$ 500

COMPRA A = R$ 400
COMPRA B = R$ 400

Dois programas consultam:

R$ 500 disponível.

A conclui:

aprovado.

B conclui:

aprovado.

Parabéns.

Acabamos de autorizar R$ 800 usando R$ 500.

Bem-vindo ao maravilhoso universo da concorrência transacional.

---

🔒 Capítulo 6 — COMMIT e ROLLBACK não são frescura

Aqui começamos a compreender por que sistemas transacionais possuem mecanismos tão sofisticados.

Nossa operação poderia ser tratada como uma Unit of Work.

BEGIN UOW
    │
    ├── READ ACCOUNT
    │
    ├── CHECK LIMIT
    │
    ├── CREATE AUTHORIZATION
    │
    ├── RESERVE LIMIT
    │
    └── WRITE AUDIT
           │
           ▼
         COMMIT

Mas imagine:

CREATE AUTHORIZATION → OK
RESERVE LIMIT        → OK
WRITE SOMETHING      → ERROR

Não podemos deixar metade da operação concluída.

Precisamos de:

ROLLBACK

A ideia fundamental é:

Ou a unidade lógica de trabalho acontece de maneira consistente, ou voltamos ao estado apropriado.

Esse é um dos conceitos que um programador COBOL iniciante deveria tatuar mentalmente.

Em aplicações financeiras, inconsistência pode significar dinheiro.

---

🧠 Capítulo 7 — O limite existe, mas devemos autorizar?

Não necessariamente.

Imagine:

LIMITE DISPONÍVEL: R$ 20.000
COMPRA:            R$ 7.000

Matematicamente:

7000 < 20000

Então aprova?

Talvez.

Agora acrescente:

CLIENTE NORMALMENTE COMPRA: Brasil
HORÁRIO:                     03:17
VALOR MÉDIO:                 R$ 80
COMPRA ATUAL:                R$ 7.000
PAÍS:                        outro país
MERCHANT:                    desconhecido

🚨

Entra o Risk/Fraud Engine.

---

🚨 Capítulo 8 — O Sherlock Holmes das transações

O sistema antifraude pode observar dezenas ou centenas de sinais.

Por exemplo:

VALUE
TIME
COUNTRY
MERCHANT
MCC
DEVICE
TRANSACTION VELOCITY
HISTORICAL BEHAVIOR
AUTHENTICATION
PREVIOUS DECLINES
GEOGRAPHICAL PATTERNS

Imagine:

23:10 São Paulo
R$ 37,50

23:18 São Paulo
R$ 83,00

23:22 Tokyo
R$ 9.700

Não precisamos ser Hercule Poirot para levantar uma sobrancelha.

Nosso sistema poderia calcular:

RISK SCORE = 947

E possuir regras como:

000-300   LOW
301-700   MEDIUM
701-850   HIGH
851-1000  DECLINE/REVIEW

Atualmente esse ambiente pode combinar regras determinísticas, estatística, análise comportamental e machine learning.

Mas COBOL continua perfeitamente capaz de executar regras determinísticas essenciais.

IF WS-RISK-SCORE > 850
    MOVE 'N' TO WS-AUTHORIZED
END-IF.

Às vezes não precisamos de inteligência artificial.

Precisamos apenas de:

IF COISA-ABSURDA
   NÃO-FAÇA
END-IF

Uma tecnologia revolucionária conhecida desde tempos imemoriais como bom senso programado.

---

⚡ Capítulo 9 — Tudo isso precisa ser rápido

Esse é um requisito extraordinário.

O consumidor está esperando.

Ele não quer ver:

PROCESSANDO...

PROCESSANDO...

PROCESSANDO...

enquanto o sistema gera um relatório gerencial de 400 páginas.

Por isso workloads diferentes possuem prioridades diferentes.

Entra o WLM — Workload Manager.

Conceitualmente:

AUTHORIZATION     CRITICAL
PAYMENT           HIGH
CUSTOMER QUERY    HIGH
REPORTING         MEDIUM
ANALYTICS BATCH   LOWER

Quando existe competição por recursos, o sistema operacional precisa compreender que:

autorizar a compra do cliente é mais urgente do que imprimir o relatório do chefe.

Embora alguns chefes possam discordar.

---

📨 Capítulo 10 — MQ: nem todo mundo precisa esperar

Imagine que a compra foi aprovada.

Precisamos responder imediatamente.

Mas também queremos:

• registrar eventos;

• enviar notificação;

• alimentar analytics;

• avisar sistemas antifraude;

• atualizar outros ambientes;

• produzir informações para aplicações móveis.

Seria absurdo fazer o consumidor esperar tudo isso.

Então:

CICS AUTH
    │
    ├──────────────► RESPONSE
    │
    │
    └──────────────► MQ
                         │
               ┌─────────┼─────────┐
               ▼         ▼         ▼
             FRAUD    ANALYTICS   ALERT
                                   │
                                   ▼
                           "Compra aprovada"

Aqui aparece uma das grandes ideias de arquitetura:

separe o caminho crítico das tarefas que podem acontecer assincronamente.

IBM MQ encaixa-se maravilhosamente nesse tipo de integração.

---

🧾 Capítulo 11 — APPROVED não significa “acabou”

Esse é provavelmente um dos conceitos mais interessantes do sistema.

A compra foi autorizada:

AUTHORIZATION

VALUE  = 100.00
STATUS = PENDING

Mas autorização e lançamento financeiro definitivo são coisas diferentes.

Posteriormente chegam informações financeiras que precisam ser conciliadas com aquela autorização.

Simplificando:

AUTHORIZATION
      │
      ▼
PRESENTMENT
      │
      ▼
MATCHING
      │
      ▼
POSTING

Finalmente:

POSTED TRANSACTION

Por que essa separação?

Porque o mundo real é bagunçado.

---

🏨 Capítulo 12 — O hotel de R$ 1.000 que virou R$ 873,42

Você chega a um hotel.

Pode ocorrer uma autorização inicial:

R$ 1.000

Sua conta final acaba sendo:

R$ 873,42

Agora nosso sistema precisa compreender que existe relacionamento entre as operações.

Situações semelhantes aparecem em:

• hotéis;

• locadoras;

• restaurantes;

• postos;

• cancelamentos;

• ajustes;

• estornos.

Portanto:

AUTHORIZATION ≠ FINAL TRANSACTION

Esse é um daqueles detalhes que parecem insignificantes até você precisar construir o sistema.

Então tornam-se gigantescos.

---

📦 Capítulo 13 — E das profundezas surge o BATCH

Durante o dia, imagine:

CICS
CICS
CICS
CICS
CICS
CICS
CICS

Transações chegando continuamente.

Em paralelo ou em determinados ciclos, precisamos executar processamento massivo.

Entra:

JES2 + JCL + COBOL Batch

Poderíamos possuir uma cadeia didática:

RECEIVE CLEARING
       │
       ▼
VALIDATE
       │
       ▼
MATCH AUTHORIZATION
       │
       ▼
POST TRANSACTION
       │
       ▼
UPDATE ACCOUNT
       │
       ▼
BILLING
       │
       ▼
SETTLEMENT
       │
       ▼
RECONCILIATION

Um JCL fictício:

//BELCARD JOB ...
//STEP010 EXEC PGM=BCLR001
//STEP020 EXEC PGM=BVAL001
//STEP030 EXEC PGM=BMAT001
//STEP040 EXEC PGM=BPOS001
//STEP050 EXEC PGM=BBIL001
//STEP060 EXEC PGM=BSET001

Cada programa possui responsabilidade específica.

Isso permite restart, controle, auditoria e operacionalização muito melhores do que construir um monstro chamado:

FAZTUDO.CBL

com 187 mil linhas.

Embora algum arqueólogo de sistemas provavelmente já tenha encontrado algo parecido.

---

🧮 Capítulo 14 — A fábrica de faturas

Chegamos ao billing.

Para cada conta precisamos considerar:

SALDO ANTERIOR
+
COMPRAS
+
PARCELAS
+
ENCARGOS
+
JUROS
-
PAGAMENTOS
-
CRÉDITOS
-
ESTORNOS
=
NOVO SALDO

Em COBOL:

COMPUTE WS-NEW-BALANCE =
        WS-PREVIOUS-BALANCE
      + WS-PURCHASES
      + WS-INSTALLMENTS
      + WS-FEES
      + WS-INTEREST
      - WS-PAYMENTS
      - WS-CREDITS.

E aqui COBOL está em casa.

Valores decimais, regras empresariais, processamento de registros e grandes volumes de dados são precisamente o tipo de problema para o qual COBOL nasceu.

---

🇧🇷 Capítulo 15 — A entidade brasileira chamada PARCELAMENTO

Agora compramos:

R$ 1.200 em 12x

Nosso sistema registra:

PURCHASE_ID = 9838172
TOTAL       = 1200.00
QTY         = 12

E teremos:

01/12  100
02/12  100
03/12  100
...
12/12  100

Parece simples.

Até alguém perguntar:

“E se houver estorno na parcela 7?”

Ou:

“E se for estorno parcial?”

Ou:

“E se o cliente contestar a compra?”

Ou:

“E se houver renegociação?”

Ou:

“E se existir juros?”

Ou:

“E se o comerciante fizer refund?”

É assim que programas pequenos envelhecem e viram programas COBOL de 30 mil linhas.

Não necessariamente porque os programadores antigos eram malucos.

Frequentemente porque 30 anos de realidade foram sendo incorporados ao código.

Essa é uma lição importantíssima para quem entra hoje no mainframe.

Código legado muitas vezes é também:

regra de negócio fossilizada.

Não apague antes de descobrir por que existe.

---

🔐 Capítulo 16 — RACF: não, estagiário, você não pode consultar todos os cartões

Nosso BELLACARD contém informações extremamente sensíveis.

Precisamos controlar:

WHO
CAN DO WHAT
TO WHICH RESOURCE
UNDER WHICH CONDITIONS

RACF pode participar do controle de acesso ao ambiente z/OS.

Podemos proteger datasets, transações, usuários, grupos e diversos recursos.

Conceitualmente:

USER VAGNER
    │
    ├── AUTH → READ/EXECUTE
    ├── BILL → READ
    └── ADMIN → NO ACCESS

O princípio essencial é:

LEAST PRIVILEGE.

Um programa deve possuir apenas os acessos necessários.

Um operador também.

Um desenvolvedor também.

E definitivamente ninguém deveria possuir acesso porque:

“Vai que um dia eu precise.”

---

🔑 Capítulo 17 — E as chaves criptográficas?

Agora entramos em território ainda mais sensível.

Cartões envolvem criptografia, autenticação, tokens, PINs e material criptográfico.

A regra de ouro é:

chaves críticas não devem virar variáveis COBOL espalhadas pela aplicação.

Algo como:

01 SUPER-SECRET-KEY PIC X(32)
   VALUE 'MINHACHAVE123...'.

é praticamente uma carta de demissão escrita em COBOL.

😂

Ambientes financeiros utilizam infraestrutura criptográfica especializada e HSMs — Hardware Security Modules — para determinadas operações e proteção de chaves.

A aplicação solicita uma operação criptográfica.

O segredo permanece protegido.

---

🕵️ Capítulo 18 — “Eu não fiz essa compra.”

Três meses depois o cliente telefona:

Eu nunca fiz essa compra.

O sistema precisa reconstruir o passado.

Queremos saber:

QUANDO?
QUAL CARTÃO?
QUAL MERCHANT?
QUAL VALOR?
QUAL CANAL?
QUAL RESPOSTA?
QUAL SISTEMA?
QUAL REGRA?
QUAL RESULTADO?

Logs e trilhas de auditoria tornam-se fundamentais.

No universo z/OS, SMF e informações produzidas pelos subsistemas ajudam a construir observabilidade e auditoria.

Nosso sistema deveria conseguir reconstruir algo como:

03:17:00.103 REQUEST RECEIVED
03:17:00.108 CARD VALIDATED
03:17:00.112 STATUS ACTIVE
03:17:00.119 LIMIT OK
03:17:00.127 RISK SCORE 214
03:17:00.133 AUTH CREATED
03:17:00.139 LIMIT RESERVED
03:17:00.145 COMMIT
03:17:00.151 APPROVED

E aí descobrimos outra característica dos sistemas financeiros:

não basta fazer certo. Precisamos conseguir demonstrar posteriormente o que aconteceu.

---

🏰 Capítulo 19 — E se o mainframe cair?

Imagine milhões de pessoas tentando pagar almoço e recebendo:

HOST UNAVAILABLE

O problema deixa rapidamente de ser “um incidente de TI”.

Vira problema comercial, financeiro e reputacional.

Daí entram conceitos de alta disponibilidade e arquiteturas como Parallel Sysplex.

Didaticamente:

                 REQUESTS
                     │
                     ▼
               WORKLOAD ROUTING
                     │
          ┌──────────┴──────────┐
          ▼                     ▼
       z/OS A                 z/OS B
        CICS                   CICS
          │                     │
          └──────────┬──────────┘
                     ▼
                   Db2
               Data Sharing

Falhou um componente?

A arquitetura é desenhada para evitar que isso necessariamente signifique:

TODO MUNDO PARA.

É aqui que redundância, recuperação, data sharing, workload management, automação operacional e engenharia de resiliência deixam de ser palavras bonitas de PowerPoint.

---

🏙️ Capítulo 20 — As duas cidades do cartão

Eu gosto de imaginar o BELLACARD dividido em duas grandes cidades.

⚡ Cidade Online

Seu prefeito é o CICS.

Sua pergunta principal:

POSSO COMPRAR?

REQUEST
   │
   ▼
CICS
   │
   ▼
CARD
LIMIT
RISK
RULES
   │
   ▼
YES / NO

Velocidade, disponibilidade e consistência dominam essa cidade.

---

🏭 Cidade Financeira

Aqui vivem:

Db2 + COBOL Batch + JES2 + MQ + sistemas contábeis.

Sua pergunta é diferente:

O QUE ACONTECEU COM O DINHEIRO?

AUTHORIZATION
      ↓
TRANSACTION
      ↓
POSTING
      ↓
ACCOUNT
      ↓
STATEMENT
      ↓
PAYMENT
      ↓
ACCOUNTING
      ↓
RECONCILIATION

Aqui cada centavo precisa encontrar seu destino.

---

🧩 Capítulo 21 — Afinal, onde cada tecnologia entra?

Agora nosso iniciante consegue enxergar o tabuleiro inteiro.

COBOL
│
├── business rules
├── authorization
├── billing
├── posting
└── batch processing

CICS
│
├── online transactions
├── transaction management
└── units of work

Db2
│
├── accounts
├── cards
├── authorizations
├── transactions
└── statements

MQ
│
├── asynchronous messaging
├── events
├── integration
└── notifications

JCL/JES2
│
├── batch
├── billing
├── reconciliation
└── settlement processing

RACF
│
└── access control

CRYPTO/HSM
│
└── sensitive cryptographic operations

SMF/MONITORING
│
├── auditing
└── observability

WLM
│
└── workload priorities

PARALLEL SYSPLEX
│
└── availability/scalability

Percebe a diferença?

Agora COBOL, CICS, Db2, MQ e JCL deixaram de ser matérias isoladas de um curso.

Cada tecnologia apareceu porque tínhamos um problema para resolver.

É assim que eu gosto de ensinar mainframe.

---

🎓 Capítulo 22 — Construindo o BELLACARD como projeto educacional

Eu transformaria essa arquitetura numa trilha prática.

O aluno começa pequeno.

Nível 1 — COBOL

Criar:

CUSTOMER
CARD
ACCOUNT

Depois:

PURCHASE
PAYMENT
LIMIT

Finalmente:

STATEMENT

---

Nível 2 — Arquivos

Guardar clientes e contas.

Começar sequencialmente.

Depois introduzir VSAM.

Agora o aluno entende por que acesso indexado importa.

---

Nível 3 — Db2

Migramos para:

CUSTOMER
ACCOUNT
CARD
AUTHORIZATION
TRANSACTION
PAYMENT
STATEMENT

Aprendemos:

SELECT
INSERT
UPDATE
DELETE
COMMIT
ROLLBACK

Não como comandos aleatórios de SQL.

Mas porque nosso banco precisa deles.

---

Nível 4 — CICS

Criamos:

AUTH = Authorization
ACCT = Account Inquiry
PAYM = Payment
BLCK = Block Card

Agora nosso COBOL deixou de ser apenas batch.

Temos um pequeno sistema transacional.

---

Nível 5 — MQ

A compra aprovada produz:

CARD.PURCHASE.APPROVED

Outro consumidor recebe.

Depois outro.

Aprendemos arquitetura assíncrona.

---

Nível 6 — Batch

Criamos:

POSTING
BILLING
PAYMENT PROCESSING
STATEMENT GENERATION
RECONCILIATION

Finalmente o aluno entende por que empresas ainda executam workloads batch gigantescos.

---

Nível 7 — Segurança

Introduzimos:

RACF
AUDIT
CRYPTOGRAPHY
TOKENIZATION

Agora nosso brinquedo começa a parecer uma plataforma empresarial.

---

Nível 8 — Operação

Provocamos problemas.

DB2 TIMEOUT
MQ QUEUE FULL
CICS ABEND
JOB RC=12
DATASET FULL
AUTHORIZATION LATENCY

E perguntamos:

O que o suporte N2 faria?

Depois:

E o N3?

Agora nasceu uma pequena War Room BELLACARD.

---

🔥 Capítulo 23 — O exercício mais importante: quebrar o sistema

Eu faria questão de criar erros propositalmente.

Por exemplo:

AVAILABLE LIMIT = 500

Disparamos simultaneamente:

PURCHASE A = 400
PURCHASE B = 400

Se ambas forem aprovadas incorretamente, descobrimos uma falha de concorrência.

Outro teste:

INSERT AUTHORIZATION = SUCCESS
UPDATE LIMIT         = FAILURE

O sistema ficou inconsistente?

Se sim:

faltou tratar corretamente a unidade de trabalho.

Outro:

MQ unavailable

A autorização precisa parar?

Talvez não.

Essa pergunta ensina arquitetura melhor que vinte slides.

---

👻 Capítulo 24 — O fantasma das 03:17

Chegamos ao easter egg.

Todos os dias exatamente às:

03:17

o BELLACARD começa a apresentar:

AUTH RESPONSE TIME
120ms
180ms
350ms
900ms
2.1s

Nenhum erro.

CPU normal.

Db2 aparentemente normal.

MQ normal.

CICS sem ABEND.

Mas a latência explode durante sete minutos.

Nosso programador iniciante recebe seu primeiro chamado:

INCIDENT #0317

SEVERITY: HIGH
DESCRIPTION:
Intermittent authorization latency.

Começa a investigação.

RMF.

SMF.

CICS statistics.

Db2 accounting.

WLM.

JES2.

Até descobrir...

Um antigo job chamado:

//MONSTR17 JOB

executado diariamente às 03:17, realizando uma consulta monstruosa contra tabelas utilizadas pelo sistema online.

O programa foi criado em 1997.

O comentário no topo:

      * DO NOT REMOVE.
      * BUSINESS REQUIREMENT.
      * JSMITH - 1997-04-13

Ninguém sabe quem é JSMITH.

Ninguém sabe qual era o requisito.

Mas todos têm medo de remover.

🤣

Bem-vindo ao mainframe corporativo.

---

🧠 Curiosidade — O verdadeiro patrimônio não é apenas o código

Esse é talvez o conhecimento mais importante de todo o artigo.

Quando alguém encontra um programa COBOL com milhares de linhas, pode pensar:

“Que coisa velha.”

Mas aquele programa pode conter décadas de:

• regras;

• exceções;

• regulamentações;

• incidentes;

• fraudes descobertas;

• produtos descontinuados;

• produtos ainda ativos;

• acordos comerciais;

• tratamentos especiais;

• correções;

• conhecimento empresarial.

É quase arqueologia.

Um comentário de 1997 pode explicar por que determinada operação de 2026 ainda funciona.

Por isso modernização responsável começa com:

compreender antes de substituir.

---

🏛️ Capítulo 25 — O mainframe como cidade invisível

Voltamos finalmente à cafeteria.

Você aproximou o cartão.

BIP!

Apareceu:

APROVADO

Você levou seu café.

Talvez nunca pense novamente naquela transação.

Mas atrás daquele pequeno momento poderia existir conceitualmente uma cidade inteira:

                   💳 CARD
                      │
                      ▼
                 POS / APP
                      │
                      ▼
                  ACQUIRER
                      │
                      ▼
               CARD NETWORK
                      │
                      ▼
╔══════════════════════════════════════╗
║               IBM Z                  ║
║                                      ║
║              CICS                    ║
║                │                     ║
║       ┌────────┼────────┐            ║
║       ▼        ▼        ▼            ║
║     CARD     LIMIT     RISK          ║
║       │        │        │            ║
║       └────────┼────────┘            ║
║                ▼                     ║
║               Db2                    ║
║                │                     ║
║               MQ                     ║
║                                      ║
║   COBOL • JCL • JES2 • RACF • SMF   ║
║        WLM • CRYPTO • SYSPLEX        ║
╚══════════════════════════════════════╝
                      │
                      ▼
                   APPROVED

O consumidor viu:

APROVADO.

O mainframer vê:

arquitetura.

---

☕ Conclusão — o BIP que esconde uma catedral

Talvez essa seja uma das melhores maneiras de explicar mainframe para alguém que está começando.

Não comece dizendo:

“COBOL possui DIVISION, SECTION e PARAGRAPH.”

Comece dizendo:

“Você acabou de passar um cartão. Quer descobrir o que pode existir atrás daquele BIP?”

Então COBOL ganha propósito.

CICS ganha propósito.

Db2 ganha propósito.

MQ ganha propósito.

JCL ganha propósito.

RACF ganha propósito.

SMF ganha propósito.

WLM ganha propósito.

Parallel Sysplex ganha propósito.

O iniciante deixa de decorar siglas e começa a compreender problemas.

E tecnologia empresarial é exatamente isso:

uma coleção de soluções para problemas que ficaram grandes demais para serem resolvidos de qualquer jeito.

Da próxima vez que aproximar seu cartão e ouvir:

BIP!

talvez você enxergue algo diferente.

Não apenas uma compra.

Mas uma mensagem atravessando redes, chegando a sistemas que verificam identidade, estado, crédito e risco; uma unidade de trabalho sendo protegida; registros sendo preservados; eventos sendo produzidos; sistemas financeiros preparando o que acontecerá depois.

Tudo isso para devolver uma pequena palavra:

       ┌────────────────────────┐
       │                        │
       │       APPROVED         │
       │                        │
       │         RC=00          │
       │                        │
       └────────────────────────┘

E talvez exista, em algum canto de algum sistema que ninguém ousa desligar, um programa COBOL escrito décadas atrás, trabalhando silenciosamente para que seu café seja pago.

Sem aplausos.

Sem interface bonita.

Sem ninguém perceber.

Como tantas outras coisas no mainframe.

Porque a melhor infraestrutura é aquela que desaparece atrás do serviço que presta.

E enquanto o mundo vê apenas o BIP, nós sabemos que atrás dele pode existir uma verdadeira catedral transacional construída byte por byte, regra por regra e geração por geração de programadores.

☕ Um Café no Bellacosa Mainframe

Onde até uma compra de R$ 17,50 pode acabar em CICS, Db2, COBOL e uma War Room às 03:17.

☕ Um Café no Bellacosa Mainframe

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

Entenda como uma compra de R$ 100 atravessa POS, adquirente, bandeira, emissor, autorização, plafond, clearing, settlement, cobrança, contabilidade e reconciliação em um ambiente bancário e mainframe.

💳 Como funciona uma transação de cartão de crédito?

Uma compra aparentemente simples percorre diversos participantes e sistemas. O cliente apresenta o cartão ao estabelecimento, a maquininha envia a transação ao adquirente, a rede encaminha a solicitação ao emissor e o banco verifica cartão, conta, produto, plafond, regras e risco antes de autorizar ou recusar.

Cardholder → Merchant → POS → Acquirer → Network → Issuer

Depois da autorização, a transação ainda pode passar por reversal, clearing, settlement, faturamento, cobrança, contabilização, reconciliação, disputa e chargeback.

Principais assuntos: IBM Mainframe, IBM Z, COBOL, CICS, Db2, cartões de crédito, POS, adquirente, emissor, autorização, plafond, clearing, settlement, tarifas, cobrança, contabilidade e reconciliação.

🔎 Ler o artigo original: The Mentalist no Mainframe

Bellacosa Mainframe — conteúdo educacional sobre IBM Z, COBOL, CICS, sistemas bancários e processamento de cartões.

Inteligência Artificial na Segurança Bancária sem Mistérios

Bellacosa Mainframe e a inteligencia artificial na seguranca bancaria

☕ Um Café no Bellacosa Mainframe

Inteligência Artificial na Segurança Bancária sem Mistérios

O Guia do Programador COBOL Padawan para Entender Biometria, Fraudes, Autenticação Contínua e os Escudos Digitais da Frota Estelar

Imagine, jovem programador COBOL Padawan, que você está sentado diante de um terminal 3270 em uma madrugada silenciosa.

Ao lado do teclado, uma caneca de café ainda quente. Na tela verde, um programa aparentemente simples processa uma transferência bancária. Ele recebe uma conta de origem, uma conta de destino, um valor e uma data. Depois de algumas validações, o sistema autoriza ou rejeita a operação.

Durante décadas, essa lógica pareceu suficiente.

O cliente informava a senha correta, o saldo era consultado, os limites eram verificados e a transação seguia seu caminho pelos corredores eletrônicos do banco.

Mas a galáxia financeira mudou.

Hoje, o usuário pode estar acessando o banco por um celular, conectado a uma rede pública, utilizando reconhecimento facial, fazendo um PIX para um novo destinatário e movimentando um valor muito diferente de seu padrão habitual.

Ao mesmo tempo, o criminoso pode possuir a senha verdadeira, o CPF, o número do telefone, documentos vazados, gravações da voz da vítima e até uma cópia artificial de seu rosto produzida por inteligência artificial.

A pergunta deixou de ser apenas:

“A senha está correta?”

Agora o banco precisa perguntar:

“Essa operação parece realmente estar sendo realizada pelo cliente?”

Essa mudança representa uma das maiores transformações na história da segurança bancária.

A segurança deixou de ser apenas um portão na entrada do sistema. Ela passou a acompanhar o cliente durante toda a jornada.

É como se os sistemas financeiros tivessem aprendido uma antiga lição da Frota Estelar:

Não basta identificar quem entrou na nave. É necessário observar o que essa pessoa faz depois de entrar.

Prepare o café, ajuste seu comunicador e abra uma nova sessão no TSO. Nossa missão será entender como inteligência artificial, biometria, autenticação multifator, análise comportamental, modelos de risco e mainframes trabalham juntos para proteger o sistema financeiro moderno.

---

1. O velho modelo: usuário, senha e confiança

Durante muito tempo, a segurança digital funcionou com uma lógica simples.

O usuário informava:

• identificação;

• senha;

• eventualmente um código adicional.

Se tudo estivesse correto, o acesso era concedido.

Em pseudocódigo COBOL, poderíamos imaginar algo assim:

IF SENHA-INFORMADA = SENHA-CADASTRADA
    MOVE 'S' TO ACESSO-AUTORIZADO
ELSE
    MOVE 'N' TO ACESSO-AUTORIZADO
END-IF

A lógica é clara, objetiva e fácil de compreender.

O problema é que ela responde apenas a uma pergunta:

A credencial apresentada corresponde à credencial armazenada?

Ela não responde:

• quem digitou a senha;

• onde a senha foi digitada;

• em qual dispositivo;

• em qual horário;

• em qual contexto;

• com qual intenção;

• se o comportamento é compatível com o histórico do cliente.

Se um criminoso roubar a senha verdadeira, o sistema tradicional poderá tratá-lo como usuário legítimo.

Esse é um dos princípios fundamentais para compreender a segurança moderna:

Uma credencial válida não significa necessariamente uma identidade legítima.

Senhas podem ser descobertas por phishing, engenharia social, vazamentos de dados, malware, observação física, reutilização em vários serviços ou manipulação psicológica.

Um cliente pode entregar voluntariamente um código de segurança acreditando estar falando com um funcionário do banco.

Nesse caso, tecnicamente, as informações estão corretas. Porém, a operação continua sendo fraudulenta.

A segurança bancária moderna precisou evoluir de uma validação estática para uma avaliação contínua de risco.

---

2. O criminoso não precisa arrombar a porta

Existe uma imagem clássica do invasor digital: alguém tentando quebrar uma senha, explorar uma falha ou invadir um servidor.

Esse tipo de ataque continua existindo.

Porém, muitos golpes atuais seguem um caminho mais silencioso.

O fraudador pode convencer a própria vítima a:

• instalar um aplicativo;

• compartilhar a tela;

• fornecer um código;

• transferir dinheiro;

• cadastrar um novo dispositivo;

• autorizar um pagamento;

• entregar informações pessoais.

O criminoso não precisa destruir os escudos da nave.

Ele pode convencer o oficial de segurança a desativá-los.

Essa é a essência da engenharia social.

Os ataques modernos exploram não apenas sistemas, mas também emoções humanas:

• medo;

• urgência;

• autoridade;

• curiosidade;

• ganância;

• confiança;

• pressão psicológica.

Uma mensagem pode dizer:

“Sua conta será bloqueada em dez minutos.”

Outra pode afirmar:

“Identificamos uma compra suspeita. Confirme seus dados agora.”

O cliente, preocupado, segue as instruções do próprio fraudador.

Por isso, proteger apenas a senha é insuficiente. O sistema precisa avaliar o contexto completo da operação.

---

3. A autenticação não termina no login

No modelo antigo, o login era considerado o grande momento da segurança.

A sequência era:

Identificação
      ↓
Senha
      ↓
Acesso autorizado

Depois do acesso, o sistema passava a confiar no usuário.

No modelo moderno, a sequência é muito mais ampla:

Identificação
      ↓
Senha ou credencial
      ↓
Biometria
      ↓
Dispositivo
      ↓
Localização
      ↓
Comportamento
      ↓
Análise de risco
      ↓
Monitoramento da sessão
      ↓
Reavaliação a cada operação

A autenticação tornou-se contínua.

Isso significa que uma sessão pode começar com baixo risco e, alguns minutos depois, apresentar sinais suspeitos.

Por exemplo:

1. O cliente acessa o aplicativo em seu celular habitual.

2. Consulta o saldo.

3. Navega normalmente.

4. Em seguida, cadastra um novo favorecido.

5. Solicita um empréstimo.

6. Transfere imediatamente todo o valor.

7. O destino é uma conta nunca utilizada.

8. O comportamento de digitação é diferente.

9. O aparelho parece estar sendo controlado remotamente.

Cada ação, isoladamente, pode ser legítima.

Porém, o conjunto forma um padrão de alto risco.

A inteligência artificial consegue observar essa sequência em tempo real e recalcular a probabilidade de fraude.

Em outras palavras, o sistema deixa de perguntar apenas:

“Quem entrou?”

E passa a perguntar constantemente:

“O que está acontecendo agora?”

---

4. Zero Trust: nunca confiar automaticamente

Um dos conceitos mais importantes da segurança moderna é o chamado Zero Trust.

O nome pode parecer severo, mas sua lógica é bastante racional:

Nunca confie automaticamente. Sempre verifique.

Isso não significa tratar todos os clientes como criminosos.

Significa não depender de uma única prova de identidade.

Mesmo um usuário autenticado precisa continuar sendo avaliado.

Na Frota Estelar, possuir um uniforme não seria suficiente para acessar o núcleo de dobra. O sistema também verificaria:

• identidade;

• patente;

• autorização;

• localização;

• horário;

• missão;

• contexto;

• nível de risco.

No setor bancário, acontece algo semelhante.

Uma transferência pode exigir verificações adicionais conforme o risco.

Por exemplo:

EVALUATE NIVEL-RISCO
    WHEN 'BAIXO'
        PERFORM AUTORIZAR-TRANSACAO
    WHEN 'MEDIO'
        PERFORM SOLICITAR-SEGUNDO-FATOR
    WHEN 'ALTO'
        PERFORM BLOQUEAR-TRANSACAO
        PERFORM GERAR-ALERTA
    WHEN OTHER
        PERFORM ENCAMINHAR-ANALISE-MANUAL
END-EVALUATE

Esse exemplo mostra um ponto importante: segurança moderna não é apenas “permitir” ou “negar”.

Ela pode aplicar diferentes respostas:

• liberar;

• solicitar biometria;

• solicitar token;

• limitar valor;

• atrasar a operação;

• enviar alerta;

• bloquear temporariamente;

• encaminhar para análise humana.

O sistema adapta a proteção ao risco observado.

---

5. A IA não procura apenas criminosos

Muitas pessoas imaginam que a inteligência artificial possui uma lista de fraudadores conhecidos e compara cada usuário com essa lista.

Isso pode fazer parte do processo, mas é apenas uma pequena parte.

Na prática, a IA busca principalmente anomalias.

Uma anomalia é algo diferente do padrão esperado.

Considere um cliente que, durante vários anos:

• acessa o aplicativo entre 7h e 22h;

• utiliza sempre o mesmo celular;

• mora no interior de São Paulo;

• movimenta valores entre R$ 50 e R$ 1.000;

• realiza pagamentos para poucos destinatários conhecidos.

Agora imagine a seguinte operação:

• acesso às 3h17;

• novo aparelho;

• nova localização;

• uso de VPN;

• tentativa de empréstimo;

• transferência de R$ 48.000;

• destinatário recém-cadastrado.

Nenhum desses elementos, sozinho, prova uma fraude.

Um cliente pode viajar, trocar de celular ou realizar uma transferência elevada.

Mas o conjunto aumenta fortemente o risco.

A IA analisa dezenas ou centenas de sinais ao mesmo tempo.

Ela não pergunta simplesmente:

“Essa pessoa é criminosa?”

Ela pergunta:

“Esse comportamento é compatível com o histórico e o contexto esperado?”

Essa diferença é essencial.

---

6. Machine Learning: ensinando o sistema a reconhecer padrões

O aprendizado de máquina, ou Machine Learning, permite que sistemas identifiquem padrões a partir de grandes volumes de dados.

Um sistema antifraude pode aprender com:

• transações legítimas;

• fraudes confirmadas;

• horários;

• valores;

• localização;

• dispositivos;

• destinatários;

• canais utilizados;

• comportamento de navegação;

• velocidade das ações;

• respostas a autenticações;

• histórico de contestação.

Imagine milhões de transações sendo processadas diariamente.

Nenhum analista humano conseguiria revisar cada uma em tempo real.

A inteligência artificial consegue calcular rapidamente a probabilidade de uma operação ser legítima ou suspeita.

Um modelo simplificado poderia considerar:

Dispositivo conhecido: risco reduzido
Localização habitual: risco reduzido
Valor muito elevado: risco aumentado
Novo favorecido: risco aumentado
Horário incomum: risco aumentado
Biometria válida: risco reduzido
Aparelho comprometido: risco elevado

O resultado final pode ser transformado em um score.

Exemplo:

Score de risco: 12 de 100
Decisão: autorizar

Outro caso:

Score de risco: 87 de 100
Decisão: bloquear e solicitar validação

Para o programador COBOL iniciante, pense no score como um campo calculado a partir de várias condições.

MOVE ZERO TO SCORE-RISCO

IF DISPOSITIVO-NOVO = 'S'
    ADD 20 TO SCORE-RISCO
END-IF

IF LOCALIZACAO-INCOMUM = 'S'
    ADD 25 TO SCORE-RISCO
END-IF

IF VALOR-ACIMA-PADRAO = 'S'
    ADD 30 TO SCORE-RISCO
END-IF

IF BIOMETRIA-VALIDA = 'S'
    SUBTRACT 20 FROM SCORE-RISCO
END-IF

Os modelos reais são muito mais complexos, mas o princípio permanece semelhante: sinais são combinados para apoiar uma decisão.

---

7. Biometria: muito além da impressão digital

A biometria utiliza características humanas para validar a identidade.

As formas mais conhecidas incluem:

• impressão digital;

• reconhecimento facial;

• voz;

• íris;

• geometria da mão.

A grande vantagem é que características biométricas são mais difíceis de compartilhar, esquecer ou digitar acidentalmente em um site falso.

Entretanto, biometria não deve ser tratada como solução mágica.

Uma fotografia pode ser roubada. Uma voz pode ser gravada. Um rosto pode ser reproduzido por deepfake.

Por isso, sistemas modernos utilizam mecanismos chamados de prova de vida, ou liveness detection.

A prova de vida tenta verificar se existe uma pessoa real diante do dispositivo.

Ela pode observar:

• profundidade facial;

• movimentos naturais;

• reflexos;

• textura da pele;

• resposta a comandos;

• movimentação dos olhos;

• sincronização labial;

• pequenas variações impossíveis em uma fotografia estática.

Um sistema pode pedir:

“Mova o rosto para a esquerda.”

Ou analisar silenciosamente características tridimensionais.

O objetivo é diferenciar uma pessoa real de:

• fotografia;

• vídeo;

• máscara;

• tela reproduzindo outro rosto;

• conteúdo sintético.

Curiosidade de bordo: em histórias de ficção científica, scanners biométricos quase sempre reconhecem rostos instantaneamente. Na vida real, iluminação, câmera, ângulo, envelhecimento e qualidade do sensor tornam o problema muito mais complexo.

---

8. Biometria comportamental: a assinatura invisível

A biometria tradicional analisa características físicas.

A biometria comportamental analisa como uma pessoa interage com o sistema.

Ela pode observar:

• ritmo de digitação;

• tempo entre teclas;

• força aplicada na tela;

• velocidade do toque;

• inclinação do aparelho;

• forma de segurar o celular;

• movimento do mouse;

• padrão de rolagem;

• tempo de leitura;

• sequência de navegação.

Imagine duas pessoas digitando a mesma senha.

A primeira digita rapidamente, utilizando os dois polegares.

A segunda faz pausas, utiliza um dedo e pressiona determinadas teclas por mais tempo.

O texto é igual, mas o comportamento é diferente.

Essas diferenças formam uma espécie de assinatura invisível.

Outro exemplo:

O cliente legítimo normalmente abre o aplicativo, verifica o saldo, consulta o extrato e depois faz uma transferência.

O fraudador pode entrar diretamente na opção de empréstimo, contratar o valor máximo e transferir imediatamente.

O caminho percorrido dentro da aplicação também é um sinal.

A grande vantagem da biometria comportamental é que ela pode funcionar silenciosamente, sem exigir ações adicionais do usuário.

O cliente legítimo percebe menos fricção.

O fraudador encontra mais barreiras.

---

9. Autenticação contextual: onde, quando, como e com quê

A autenticação contextual analisa as circunstâncias da operação.

Entre os sinais avaliados estão:

• localização;

• endereço IP;

• operadora;

• rede Wi-Fi;

• horário;

• idioma;

• fuso horário;

• modelo do dispositivo;

• versão do sistema;

• navegador;

• resolução da tela;

• presença de VPN;

• histórico do aparelho.

Imagine um cliente que mora em Campinas e acessa o banco às 14h.

Cinco minutos depois, ocorre outro acesso a partir de outro continente.

Fisicamente, isso seria impossível.

Esse tipo de evento pode ser classificado como viagem impossível.

O sistema pode bloquear a nova sessão ou solicitar validação adicional.

Outro exemplo:

Um cliente sempre utiliza o aplicativo em um aparelho Android específico. De repente, ocorre um acesso em um emulador, com sistema modificado e ferramentas de automação.

Esse contexto aumenta o risco, mesmo que a senha esteja correta.

A autenticação contextual não substitui a senha ou a biometria. Ela adiciona mais evidências.

É como uma investigação vulcana: nenhuma conclusão é baseada em uma única pista.

---

10. Token e autenticação multifator

A autenticação multifator combina diferentes tipos de prova.

Os fatores costumam ser divididos em três categorias:

Algo que você sabe

• senha;

• PIN;

• resposta secreta.

Algo que você possui

• celular;

• cartão;

• token físico;

• aplicativo autenticador.

Algo que você é

• rosto;

• impressão digital;

• voz;

• íris.

Usar dois ou mais fatores reduz o risco de uma única credencial comprometida permitir acesso completo.

Porém, até a autenticação multifator pode ser atacada.

Códigos podem ser interceptados. Usuários podem ser convencidos a aprovar notificações. Chips podem ser clonados ou transferidos ilegalmente.

Por isso, o setor caminha para uma combinação mais ampla:

Senha
+
Dispositivo
+
Biometria
+
Contexto
+
Comportamento
+
Análise de risco

Quanto mais coerentes forem os sinais, maior a confiança.

Quanto mais contraditórios, maior a necessidade de verificação.

---

11. A luta contra falsos positivos

Bloquear fraudes é importante.

Mas bloquear clientes legítimos também causa problemas.

Imagine um cliente tentando pagar uma cirurgia, comprar uma passagem ou transferir dinheiro em uma emergência. Se o banco bloquear a operação sem necessidade, a experiência será péssima.

Isso é chamado de falso positivo.

Um falso positivo ocorre quando uma operação legítima é classificada como fraude.

Já um falso negativo ocorre quando uma fraude é classificada como legítima.

O grande desafio é equilibrar os dois.

Se o sistema for rígido demais, bloqueia clientes honestos.

Se for permissivo demais, deixa passar fraudes.

A inteligência artificial ajuda a encontrar um equilíbrio mais preciso.

Em vez de criar uma regra fixa como:

Toda transferência acima de R$ 10.000 deve ser bloqueada.

O sistema pode analisar:

• renda do cliente;

• histórico;

• destinatário;

• horário;

• dispositivo;

• localização;

• motivo;

• frequência;

• comportamento.

Para um cliente, R$ 10.000 pode ser altamente incomum.

Para outro, pode ser uma operação diária.

A análise precisa ser contextual.

---

12. Aprendizado contínuo: o inimigo também evolui

Fraudadores testam constantemente novas técnicas.

Quando os bancos melhoram a autenticação, surgem novos golpes de engenharia social.

Quando os sistemas detectam determinados padrões, os criminosos tentam imitá-los.

Quando a biometria facial avança, aparecem deepfakes mais sofisticados.

É uma corrida permanente.

Por isso, modelos antifraude precisam ser atualizados continuamente.

O ciclo pode ser representado assim:

Fraude acontece
      ↓
Caso é investigado
      ↓
Padrão é identificado
      ↓
Modelo é ajustado
      ↓
Novas transações são protegidas
      ↓
Resultados são monitorados

Esse processo exige participação humana.

Analistas investigam alertas, confirmam fraudes, corrigem classificações e ajudam a melhorar os modelos.

A inteligência artificial não elimina o especialista.

Ela amplia sua capacidade.

Um analista que antes revisava cem casos pode concentrar-se nos casos mais críticos, enquanto o sistema automatiza a triagem inicial.

---

13. Inteligência artificial generativa na segurança bancária

Além dos modelos tradicionais de Machine Learning, a inteligência artificial generativa também pode apoiar equipes de segurança.

Ela pode:

• resumir alertas;

• explicar motivos de bloqueio;

• organizar evidências;

• gerar relatórios;

• auxiliar investigações;

• consultar políticas internas;

• traduzir documentos;

• correlacionar eventos;

• apoiar equipes de atendimento.

Imagine um analista recebendo milhares de logs.

Uma IA pode produzir um resumo:

“A operação foi classificada como alto risco devido a novo dispositivo, localização incomum, valor 14 vezes superior à média e cadastramento recente do beneficiário.”

Isso reduz o tempo necessário para entender o caso.

Porém, decisões críticas não devem depender cegamente de uma resposta gerada.

Modelos generativos podem cometer erros, interpretar dados incorretamente ou produzir explicações convincentes, porém falsas.

Por isso, devem operar com:

• dados confiáveis;

• limites claros;

• revisão humana;

• rastreabilidade;

• controle de acesso;

• monitoramento.

Na ponte da nave, a IA pode ser um excelente oficial científico. Mas o comando final ainda exige responsabilidade.

---

14. LGPD, privacidade e governança

Quanto mais dados são analisados, maior a responsabilidade.

Sistemas antifraude podem processar:

• identidade;

• localização;

• comportamento;

• dispositivo;

• histórico financeiro;

• biometria;

• dados de navegação.

Essas informações são extremamente sensíveis.

No Brasil, a LGPD estabelece princípios para o tratamento de dados pessoais.

Os bancos precisam considerar:

• finalidade;

• necessidade;

• transparência;

• segurança;

• prevenção;

• responsabilização;

• direitos do titular.

Não basta dizer:

“Usamos muitos dados porque segurança é importante.”

A instituição precisa demonstrar:

• por que os dados são necessários;

• como são protegidos;

• quem pode acessá-los;

• por quanto tempo são mantidos;

• como decisões são tomadas;

• como incidentes são tratados.

Também existem exigências relacionadas a:

• prevenção à lavagem de dinheiro;

• conhecimento do cliente;

• monitoramento de operações;

• auditoria;

• gestão de riscos;

• identidade digital;

• controles internos.

A segurança precisa proteger o cliente sem transformar o sistema em uma máquina de vigilância sem limites.

Esse equilíbrio é um dos maiores desafios éticos e regulatórios da era da IA.

---

15. IA explicável e responsabilidade

Imagine receber a seguinte mensagem:

“Sua transação foi bloqueada pela inteligência artificial.”

Isso não explica nada.

Em sistemas críticos, decisões precisam ser auditáveis.

O banco deve conseguir responder:

• qual modelo tomou a decisão;

• qual versão estava em uso;

• quais dados foram considerados;

• quais sinais aumentaram o risco;

• quem revisou o caso;

• qual política foi aplicada.

Esse campo é conhecido como Explainable AI, ou IA explicável.

Nem todo modelo complexo é fácil de explicar. Porém, instituições financeiras precisam buscar formas de tornar decisões compreensíveis e rastreáveis.

Um relatório pode mostrar:

Motivos principais do bloqueio:

1. Novo dispositivo.
2. Localização incompatível.
3. Transferência 20 vezes superior à média.
4. Beneficiário cadastrado há menos de cinco minutos.
5. Comportamento de navegação fora do padrão.

Isso ajuda:

• analistas;

• auditores;

• reguladores;

• atendimento;

• clientes;

• equipes jurídicas.

A responsabilidade não pode ser transferida para a máquina.

Dizer “o algoritmo decidiu” não encerra a discussão.

---

16. Onde entra o mainframe?

Agora chegamos ao território familiar do programador COBOL Padawan.

Muitos grandes bancos continuam utilizando mainframes para processar operações críticas.

O IBM Z pode participar de funções como:

• manutenção de contas;

• atualização de saldos;

• processamento de cartões;

• liquidação;

• crédito;

• cadastro;

• movimentação financeira;

• auditoria;

• processamento em lote;

• integração com redes externas.

A inteligência artificial não necessariamente substitui esses sistemas.

Ela pode atuar ao redor deles ou integrada a eles.

Uma arquitetura simplificada poderia ser:

Aplicativo móvel
      ↓
API de autenticação
      ↓
Biometria e análise de dispositivo
      ↓
Motor antifraude com IA
      ↓
Score de risco
      ↓
API bancária
      ↓
CICS / IMS / Db2 / COBOL
      ↓
Autorização ou rejeição

O programa COBOL pode receber um indicador de risco.

Exemplo:

01  DADOS-TRANSACAO.
    05 CONTA-ORIGEM        PIC 9(10).
    05 CONTA-DESTINO       PIC 9(10).
    05 VALOR-TRANSACAO     PIC 9(11)V99.
    05 SCORE-RISCO         PIC 9(03).
    05 STATUS-BIOMETRIA    PIC X.
    05 DISPOSITIVO-NOVO    PIC X.

IF SCORE-RISCO GREATER THAN 80
    MOVE 'B' TO STATUS-TRANSACAO
    PERFORM REGISTRAR-BLOQUEIO
ELSE
    PERFORM PROCESSAR-TRANSFERENCIA
END-IF

Esse é apenas um exemplo didático.

Em uma arquitetura real, a decisão pode envolver motores especializados, regras, APIs, filas, eventos, banco de dados, monitoração e aprovação humana.

O ponto principal é:

O mainframe não está separado da inteligência artificial. Ele pode ser parte central da cadeia de decisão.

A IA funciona como sensor e oficial de análise.

O core bancário funciona como motor transacional.

Ambos precisam conversar de maneira rápida, confiável e segura.

---

17. Passo a passo de uma transação moderna

Vamos acompanhar uma transferência do início ao fim.

Passo 1 — O cliente abre o aplicativo

O sistema identifica:

• modelo do aparelho;

• versão do sistema;

• endereço IP;

• localização aproximada;

• integridade do dispositivo;

• histórico de uso.

Passo 2 — O cliente autentica

Pode utilizar:

• senha;

• PIN;

• impressão digital;

• reconhecimento facial;

• token.

Passo 3 — O comportamento é observado

O sistema analisa:

• velocidade de navegação;

• forma de digitação;

• sequência de telas;

• padrão de toque;

• tempo de resposta.

Passo 4 — A transferência é criada

São coletados:

• valor;

• destinatário;

• banco;

• horário;

• frequência;

• histórico entre as contas.

Passo 5 — A IA calcula o risco

O modelo compara a operação com:

• padrão do cliente;

• padrões de fraude;

• comportamento de contas semelhantes;

• alertas recentes;

• reputação do dispositivo;

• sinais de comprometimento.

Passo 6 — O motor de decisão atua

A operação pode ser:

• aprovada;

• aprovada com limite;

• submetida a biometria;

• submetida a segundo fator;

• colocada em espera;

• bloqueada;

• enviada para análise.

Passo 7 — O core bancário processa

O sistema transacional verifica:

• saldo;

• limite;

• situação da conta;

• regras financeiras;

• disponibilidade;

• consistência.

Passo 8 — Tudo é registrado

Logs e trilhas de auditoria armazenam:

• decisão;

• horário;

• modelo;

• score;

• fatores utilizados;

• resultado final.

Passo 9 — O sistema aprende

Se a operação for confirmada como fraude, o caso pode alimentar melhorias futuras.

Se o cliente confirmar que era legítima, o sistema também aprende.

Esse ciclo acontece milhões de vezes.

---

18. Dicas para o programador COBOL Padawan

Mesmo que você não trabalhe diretamente com IA, existem conhecimentos importantes para sua carreira.

Entenda a origem dos dados

Pergunte sempre:

• quem gerou o score;

• quando foi calculado;

• qual o formato;

• qual a validade;

• o que fazer se estiver ausente.

Nunca confie cegamente em um campo externo

Um score recebido por API precisa ser validado.

IF SCORE-RISCO NOT NUMERIC
    PERFORM TRATAR-ERRO
END-IF

Registre decisões importantes

Operações críticas precisam de auditoria.

Não basta bloquear. É necessário registrar por quê.

Trate indisponibilidade

O que acontece se o motor de IA estiver fora do ar?

O sistema deve:

• bloquear tudo;

• liberar operações de baixo valor;

• usar regras locais;

• encaminhar para contingência?

Essa decisão precisa ser definida antecipadamente.

Evite decisões sem explicação

Um campo “RISCO-ALTO” pode ser insuficiente.

Sempre que possível, receba códigos de motivo.

01 — Dispositivo novo
02 — Valor anormal
03 — Localização suspeita
04 — Beneficiário recente

Proteja dados sensíveis

Logs não devem expor:

• senha;

• token;

• biometria;

• número completo de cartão;

• informações pessoais desnecessárias.

Pense em performance

Uma análise antifraude não pode levar vários segundos durante uma compra.

Tempo de resposta é parte da experiência e da arquitetura.

Conheça o fluxo completo

O programador não deve enxergar apenas o programa COBOL.

Ele deve compreender:

• canal digital;

• API;

• mensageria;

• motor de risco;

• CICS;

• Db2;

• logs;

• monitoração;

• atendimento;

• auditoria.

É assim que um Padawan se transforma em arquiteto da Frota.

---

19. Curiosidades da galáxia antifraude

Curiosidade 1 — Seu jeito de usar o celular pode identificá-lo

A forma como você inclina o aparelho, toca a tela e digita pode compor um padrão comportamental.

Curiosidade 2 — Uma transação legítima pode parecer suspeita

Comprar uma passagem internacional, trocar de telefone e fazer uma transferência elevada no mesmo dia pode gerar alertas, mesmo sendo legítimo.

Curiosidade 3 — Fraude não é apenas invasão de conta

Também pode envolver:

• abertura de conta falsa;

• documentos adulterados;

• crédito obtido ilegalmente;

• lavagem de dinheiro;

• uso de contas de terceiros;

• identidades sintéticas.

Curiosidade 4 — O cliente pode estar autenticado e ainda assim ser vítima

Em golpes de falsa central, a própria vítima realiza a operação sob orientação do criminoso.

Nesse caso, senha, biometria e dispositivo podem estar corretos.

A análise comportamental e contextual torna-se ainda mais importante.

Curiosidade 5 — Regras antigas ainda têm valor

A IA não elimina regras tradicionais.

Muitas arquiteturas combinam:

• regras fixas;

• modelos estatísticos;

• Machine Learning;

• listas de bloqueio;

• análise humana.

A melhor defesa costuma ser híbrida.

---

20. Easter egg para quem chegou até aqui

Em algum ponto desta missão, talvez você tenha percebido que o sistema antifraude se comporta como o computador da USS Enterprise.

Ele observa milhares de sensores, compara padrões, calcula probabilidades e alerta a tripulação quando algo foge do esperado.

Mas existe uma diferença importante.

Nos episódios clássicos, o computador frequentemente anunciava:

“Intruder alert.”

Nos bancos modernos, o alerta pode ser muito mais discreto.

Talvez o cliente apenas receba uma solicitação de biometria adicional.

Talvez a transferência seja atrasada por alguns segundos.

Talvez um analista receba uma notificação.

Talvez um programa COBOL execute um simples:

MOVE 'N' TO TRANSACAO-AUTORIZADA

Por trás desse único caractere podem existir:

• milhões de registros;

• dezenas de algoritmos;

• centenas de sinais;

• decisões regulatórias;

• motores de risco;

• APIs;

• mainframes;

• criptografia;

• auditoria;

• análise humana.

O humilde MOVE 'N' pode ser o último escudo antes de uma fraude milionária.

Essa é a beleza invisível dos sistemas corporativos.

---

Conclusão: os novos escudos da Frota Financeira

A segurança bancária não pode mais depender apenas de senhas.

O cenário moderno exige uma combinação de:

• inteligência artificial;

• biometria;

• autenticação multifator;

• análise comportamental;

• contexto;

• tokens;

• monitoramento contínuo;

• governança;

• auditoria;

• intervenção humana.

A IA permite analisar enormes volumes de transações em tempo real, identificar comportamentos anormais, calcular riscos e responder antes que o prejuízo aconteça.

A biometria ajuda a validar identidade.

A análise comportamental observa como o cliente interage.

A autenticação contextual avalia onde, quando e em qual dispositivo a operação ocorre.

O mainframe garante que a transação seja processada com consistência, disponibilidade e segurança.

Nenhuma dessas tecnologias funciona perfeitamente sozinha.

A verdadeira força está na integração.

Assim como uma nave da Frota Estelar depende de sensores, escudos, computadores, motores, oficiais e protocolos, um banco moderno depende de várias camadas trabalhando em conjunto.

Para o programador COBOL iniciante, a principal lição é clara:

O código que processa uma transação é apenas uma parte de uma missão muito maior.

Por trás de cada autorização existem decisões de segurança, dados, modelos, regras, APIs, auditoria e responsabilidade.

Aprender COBOL continua sendo importante.

Mas compreender o ecossistema ao redor do COBOL é o que transforma um simples programador em um profissional preparado para os sistemas financeiros do futuro.

Quando você encontrar no código um campo chamado SCORE-RISCO, STATUS-BIOMETRIA, IND-FRAUDE ou COD-MOTIVO-BLOQUEIO, não o veja apenas como mais uma variável.

Veja-o como uma mensagem enviada pelos sensores da nave.

Analise.

Valide.

Registre.

Proteja.

E nunca se esqueça da principal diretriz da segurança moderna:

Confiança não é um estado permanente. É uma conclusão que precisa ser reavaliada continuamente.

Vida longa ao COBOL.

Vida longa ao mainframe.

E que os escudos permaneçam ativos em todas as transações da galáxia financeira.