☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

Mostrar mensagens com a etiqueta PIX. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta PIX. Mostrar todas as mensagens

sexta-feira, 14 de agosto de 2026

Como o ChatGPT Trollou Bellacosa e Ele Descobriu que Era a Formiguinha

Bellacosa Mainframe e como fui trollado pelo chatgpt


☕ Um Café no Bellacosa Mainframe

Como o ChatGPT Trollou Bellacosa e Ele Descobriu que Era a Formiguinha

🐜 Engenharia social, Red Team, crime organizado, confiança, terceirização, Swiss Cheese e o glorioso momento em que o especialista percebeu: “PUTA QUE PARIU, CAÍ NO MEU PRÓPRIO ARTIGO.”

Existe uma regra não escrita no universo.

Se você passar tempo suficiente explicando como alguma coisa pode dar errado, eventualmente o universo fará uma demonstração prática usando você como voluntário.

Foi exatamente o que aconteceu comigo.

Eu estava conversando com o ChatGPT sobre segurança.

Nada particularmente estranho para quem acompanha o Bellacosa Mainframe.

O problema é que a conversa começou inocentemente com fraude financeira, passou por crime organizado, inteligência, agentes infiltrados, terceirização, engenharia social, análise de grafos, Swiss Cheese Model, funcionários cooptados, redes sociais e terminou comigo olhando para uma tela dizendo:

Verificação concluída. Sua identidade foi verificada e o acesso confiável agora está ativo.

Silêncio.

Olhei para a tela.

Olhei novamente.

E meu cérebro produziu uma das frases mais sinceras de toda a minha carreira profissional:

“PUTA QUE PARIU. CAÍ NO MEU PRÓPRIO ARTIGO.”

🐜

Mas precisamos voltar algumas horas.


🧀 Tudo começou com um queijo

A discussão era sobre uma pergunta aparentemente simples:

quanto precisaria valer uma fraude para justificar que uma organização criminosa investisse durante anos na construção de uma empresa aparentemente legítima?

Imagine um e-commerce.

Produtos verdadeiros.

Clientes verdadeiros.

Cartões verdadeiros.

Entregas verdadeiras.

Fornecedores verdadeiros.

Funcionários verdadeiros.

Impostos.

Marketing.

Atendimento.

Reclamações.

Promoções.

Black Friday.

Tudo absolutamente normal.

Só que existe uma pergunta de Red Team:

e se a empresa possuir também uma segunda finalidade?

Não necessariamente executar o ataque.

Talvez simplesmente observar.

Aprender.

Acumular conhecimento.

Construir relacionamentos.

Entender como o ecossistema financeiro responde.

A partir daí surgiu nossa empresa hipotética.

Naturalmente escolhemos um nome discreto:

ToyanHorse

Sim.

ToyanHorse.

Se você ainda não percebeu, leia devagar.

Toyan Horse.

Trojan Horse.

Cavalo de Troia.

Maquiavel provavelmente pediria participação societária.


🐴 O melhor Cavalo de Troia não precisa atacar

Essa foi a primeira descoberta interessante.

Normalmente imaginamos o Cavalo de Troia carregando soldados.

Mas uma empresa adversarial hipotética nem precisaria participar da operação final.

Ela poderia simplesmente produzir inteligência.

Durante anos:

ToyanHorse → observa → aprende → relaciona → acumula

Enquanto outra estrutura:

recebe → correlaciona → planeja → eventualmente age

Se algum escândalo acontecesse anos depois, talvez ninguém encontrasse uma conexão operacional direta entre o ataque e a ToyanHorse.

Porque estavam procurando:

quem executou o ataque?

Quando outra pergunta poderia ser:

quem forneceu o conhecimento necessário para planejá-lo?

Foi aí que apareceu nossa formiguinha.


🐜 A formiguinha

Imagine um profissional terceirizado.

Depois quarteirizado.

Depois quinteirizado.

Ele entra em uma instituição.

Possui crachá.

Chamado.

Usuário.

Senha.

Autorização.

Contrato.

Tudo correto.

Ele trabalha.

Entrega.

Participa de reuniões.

Resolve incidentes.

Conversa no café.

Aprende workflows.

Conhece pessoas.

Descobre quem realmente decide.

Entende onde ficam as dependências.

Vê parcialmente a arquitetura.

Depois vai embora.

USERID REVOKED

VPN REVOKED

BADGE REVOKED

Tudo verde.

Auditoria satisfeita.

Só existe um pequeno problema:

REVOKE KNOWLEDGE FROM BELLACOSA

COMMAND NOT FOUND.

O conhecimento saiu andando pela porta da frente.


🐜🐜🐜 E a formiguinha muda de formigueiro

Agora imagine:

Banco A

Consultoria B

Telecom C

Adquirente D

Fornecedor E

Banco F

Em vinte anos, um excelente profissional pode construir um mapa mental extraordinário de todo um setor.

Isso normalmente é maravilhoso.

Chamamos isso de:

experiência.

É justamente por isso que contratamos profissionais seniores.

Mas o Red Team precisa fazer uma pergunta desagradável:

E se alguém com essa mesma trajetória estiver trabalhando para outro interesse?

Ele não precisa sabotar nada.

Não precisa roubar banco de dados.

Não precisa instalar malware.

Talvez nunca viole uma única política.

Ele apenas:

trabalha → observa → aprende → lembra.

E passa adiante conhecimento.

A organização procura comportamento suspeito.

Não existe.

O SIEM procura eventos.

Não existem.

O DLP procura arquivos.

Nada saiu.

O IAM verifica os acessos.

Todos legítimos.

Porque não existe evento:

USER HAS JUST UNDERSTOOD SOMETHING VERY IMPORTANT

💰 E então lembramos do Pix

Foi aí que nossa conversa deixou de ser puramente hipotética.

O grande incidente envolvendo a infraestrutura conectada ao ecossistema Pix mostrou uma coisa desconfortável:

às vezes a peça humana aparentemente pequena possui um valor operacional gigantesco.

E apareceu uma ideia que passei a chamar de:

Teste da Formiguinha

Não pergunte somente:

“Quanto esse funcionário ganha?”

Pergunte:

“Quanto vale aquilo que ele consegue alcançar?”

São números completamente diferentes.

Uma organização pode enxergar:

TERCEIRIZADO

O adversário pode enxergar:

CAPACIDADE

O organograma mostra hierarquia.

O grafo mostra centralidade.

E nasceu uma frase que resume boa parte desta história:

O organograma mostra quem tem poder na empresa. O grafo mostra quem tem poder sobre o sistema.


🧀 O queijo suíço

Naturalmente chegamos ao Swiss Cheese Model.

Uma organização possui várias barreiras:

🧀 autenticação

🧀 segregação de funções

🧀 compliance

🧀 auditoria

🧀 fornecedores certificados

🧀 monitoramento

🧀 políticas

🧀 treinamento

Cada camada possui furos.

Normalmente os furos não coincidem.

Mas às vezes:

○ → ○ → ○ → ○ → ○

Alinham.

E temos um caminho.

A versão Bellacosa do Swiss Cheese ficou um pouco menos acadêmica:

Quando todos os furos se alinham, o queijo corporativo ganha um glory hole.

Peço desculpas aos acadêmicos.

Mentira.

Não peço.

Vocês nunca mais esquecerão o conceito.


📋 “Mas fomos auditados!”

Foi quando comecei a rir.

Porque ouvi essa frase durante décadas.

“Mas fomos auditados.”

Enron era auditada.

Wirecard era auditada.

Carillion era auditada.

Uma enorme quantidade de organizações que protagonizaram escândalos possuía auditores, conselhos, controles, compliance e supervisão.

Auditoria é importante.

Mas auditoria é:

mais uma fatia de queijo.

O auditor pergunta:

“O controle está funcionando?”

O Red Team pergunta:

“Como consigo atingir meu objetivo apesar desse controle?”

Perguntas completamente diferentes.


📱 Então apareceu outro aliado involuntário

Redes sociais.

Não apenas porque revelam relações profissionais.

Existe outra coisa.

Comparação.

Abra o feed:

Dubai.

Porsche.

Maldivas.

Rolex.

Restaurante.

Cobertura.

Champagne.

“Conquistei minha independência financeira aos 23.”

Enquanto nossa formiguinha está trabalhando em infraestrutura crítica através da quarta empresa da cadeia de terceirização.

Isso não transforma ninguém em criminoso.

Mas existe um conceito importante:

privação relativa.

Não importa apenas quanto alguém possui.

Importa quanto acredita que deveria possuir comparando-se com os outros.

Então apareceu uma pergunta ainda mais desagradável:

Quanto custa contratar uma pessoa e quanto custaria para um adversário tentar corrompê-la?

Novamente:

dois números completamente diferentes.


🕵️ E percebemos que estávamos construindo um serviço de inteligência

Empresas.

Telecomunicações.

Infraestrutura.

Pessoas.

OSINT.

Dados.

Relacionamentos.

Conhecimento.

IA.

Grafos.

Subitamente apareceu outra conclusão:

capacidades que décadas atrás exigiam estruturas estatais enormes ficaram muito mais acessíveis.

Uma organização criminosa não precisa construir sua própria CIA.

Precisa apenas ser suficientemente boa em um domínio específico.

E uma IA nem precisaria atacar nada.

Poderia simplesmente ajudar a relacionar fragmentos:

🐜 fragmento A

🐜 fragmento B

🐜 fragmento C

🐜 fragmento D

correlação

grafo

O verdadeiro ativo talvez não seja o dado.

É o modelo mental produzido pelos dados.


🐴 Voltamos então à ToyanHorse

E percebemos algo ainda mais perverso.

O e-commerce nem precisa perder dinheiro.

Ele pode ser lucrativo.

Clientes verdadeiros.

Receita verdadeira.

Operação verdadeira.

A cobertura paga a própria cobertura.

Então nossa pergunta original estava parcialmente errada.

Não era:

“Quanto precisaria valer o ataque para justificar manter uma empresa durante cinco anos?”

Era:

“E se a empresa já der lucro enquanto acumula capacidades úteis?”

Bombril criminoso.

Mil e uma utilidades.


🚨 E então aconteceu

Depois de horas falando sobre:

engenharia social,

confiança,

identidade,

coleta de informação,

Cavalo de Troia,

insiders,

formiguinhas,

adversários,

e pessoas que entregam informações porque determinada solicitação parece legítima...

apareceu uma tela.

ChatGPT

Verificação concluída

Sua identidade foi verificada e o acesso confiável agora está ativo.

Eu tinha passado por uma verificação relacionada ao acesso confiável para trabalho de cibersegurança.

Olhei para aquilo.

Meu cérebro finalmente conectou os pontos.

IDENTIDADE.

DOCUMENTO.

INTERNET.

CONFIANÇA.

...

...

...

PUTA QUE PARIU.

CAÍ NO MEU PRÓPRIO ARTIGO.

🐤


🐜 O Dia em que a Formiguinha Era Eu

Por alguns segundos houve medo verdadeiro.

Não medo acadêmico.

Não ameaça hipotética.

Não Red Team.

Aquele frio genuíno:

“Bellacosa, seu animal, você passou horas explicando engenharia social e acabou entregando documento para alguém na Internet?”

Mel Brooks não escreveria melhor.

Imagine a cena.

O velho especialista barbudo passa duas horas diante da plateia:

“Nunca confiem simplesmente na aparência!”

Slide seguinte:

“Validem identidade!”

Slide seguinte:

“Engenharia social explora contexto!”

Slide seguinte:

“O adversário quer que a solicitação pareça normal!”

Aluno levanta a mão:

“Professor, e aquela verificação que o senhor fez hoje?”

Silêncio.

Café cai no chão.

Zoom no rosto.

Violinos.

FIM.


🔨 Chamem o MythBusters

Então fizemos exatamente aquilo que deveríamos fazer.

Não concluímos:

“FUI HACKEADO!”

Também não concluímos:

“Sou especialista, obviamente estava tudo certo.”

Verificamos.

A documentação oficial confirmou a existência daquele processo de acesso confiável relacionado à segurança.

Era legítimo.

Adam Savage aparece.

Martelo na mão.

BUSTED.

Bellacosa não havia caído num phishing enquanto escrevia sobre phishing.

O ego, entretanto, permaneceu indisponível durante aproximadamente quinze minutos.


🧠 E aí veio a verdadeira lição

Especialistas também sentem medo.

Especialistas também clicam.

Especialistas também confiam.

Especialistas também podem interpretar uma situação incorretamente.

Conhecimento não transforma ninguém em firewall humano infalível.

E talvez seja justamente essa arrogância:

“Isso jamais aconteceria comigo.”

que represente um dos maiores furos do queijo.

A reação saudável é outra:

“Espera. Isso faz sentido? Vamos verificar.”

Foi exatamente o que aconteceu.


🐜 O Teste da Formiguinha

Depois dessa conversa, eu acrescentaria uma pergunta a qualquer exercício sério de Red Team:

Qual é a pessoa aparentemente menos importante cuja mudança de comportamento poderia produzir um impacto desproporcional?

Não para suspeitar dela.

Para avaliar o sistema.

Suponha:

erro.

Coerção.

Cooptação.

Credencial comprometida.

Engenharia social.

O que acontece?

Se a resposta for:

“Essa pessoa sozinha consegue abrir um caminho enorme.”

não encontramos uma pessoa perigosa.

Encontramos uma arquitetura perigosa.


🧀 O último queijo

Existe uma última ironia.

Começamos tentando imaginar criminosos extremamente sofisticados.

Empresas.

Inteligência.

IA.

Operações transnacionais.

Insiders.

Infraestrutura.

E talvez a grande conclusão seja muito mais humilde:

sistemas gigantescos continuam dependendo de pessoas pequenas.

Pessoas que almoçam.

Pessoas que ficam cansadas.

Pessoas que querem ganhar mais.

Pessoas que confiam.

Pessoas que sentem medo.

Pessoas que mudam de emprego.

Pessoas que aprendem.

Pessoas que erram.

Pessoas como eu.

🐜

Por alguns segundos, depois de décadas trabalhando com tecnologia, eu fui a formiguinha.

E talvez tenha sido a melhor demonstração possível de toda a tese.

Porque segurança não começa quando afirmamos:

“Eu jamais cairia nisso.”

Segurança começa quando conseguimos perguntar:

“E se eu cair?”

E construímos o sistema para sobreviver mesmo assim.


Um Café no Bellacosa Mainframe

Onde hoje descobrimos que você pode estudar o Cavalo de Troia durante décadas, desenhar todos os queijos suíços, mapear todas as formigas...

...e ainda terminar a noite olhando assustado para o monitor e pensando:

“Puta que pariu. A formiguinha sou eu.”

🐜☕

segunda-feira, 15 de junho de 2026

☕🚀 Os Maiores Bancos Digitais do Brasil Nasceram na Nuvem, Mas o Dinheiro Ainda Passa pelo Mainframe

 

Bellacosa Mainframe e uma visão do sistema bancario brasileiro

☕🚀 Os Maiores Bancos Digitais do Brasil Nasceram na Nuvem, Mas o Dinheiro Ainda Passa pelo Mainframe

Existe uma frase que se tornou quase um mantra no mercado financeiro moderno:

"O futuro está na nuvem."

E é verdade.

Nubank, Inter, Mercado Pago, PicPay, PagBank e dezenas de fintechs brasileiras nasceram em arquiteturas modernas, utilizando APIs, microsserviços, containers, Kubernetes, inteligência artificial e infraestrutura cloud.

Mas existe uma realidade pouco comentada fora dos bastidores da tecnologia bancária.

Uma realidade que surpreende estudantes, jornalistas, executivos recém-chegados ao setor financeiro e até muitos profissionais de TI.

O dinheiro que movimenta bilhões de reais diariamente no Brasil continua passando por sistemas centrais executados em plataformas que nasceram décadas antes da internet comercial.

Sim.

Enquanto o cliente faz um PIX em um smartphone equipado com processadores capazes de executar bilhões de operações por segundo, uma parte significativa da infraestrutura que garante que aquele dinheiro chegue ao destino continua rodando em ambientes IBM Z, CICS, DB2, MQ e COBOL.

E isso não acontece por nostalgia.

Acontece porque funciona.

Muito bem.


O mito do "banco 100% digital"

Quando um banco digital aparece na televisão, geralmente a propaganda mostra:

  • aplicativo moderno;

  • cartão colorido;

  • conta aberta em minutos;

  • chatbot inteligente;

  • investimentos com poucos cliques.

Tudo parece novo.

Tudo parece revolucionário.

Tudo parece distante do mundo dos grandes datacenters.

Mas existe uma diferença importante entre:

interface digital
e
infraestrutura financeira.

O cliente enxerga o aplicativo.

O sistema financeiro enxerga liquidação.

E são coisas completamente diferentes.

Um banco pode ter uma experiência totalmente digital e, ainda assim, depender de sistemas centrais extremamente robustos para realizar:

  • liquidação financeira;

  • compensação;

  • controle contábil;

  • reconciliação;

  • registro de operações;

  • cálculo de tarifas;

  • processamento de empréstimos;

  • integração com o Banco Central.

É nesse momento que entram os sistemas de missão crítica.


O que acontece quando você faz um PIX?

Vamos imaginar uma situação extremamente comum.

Você abre o aplicativo.

Transfere R$ 100 para um amigo.

A operação parece instantânea.

Na tela tudo ocorre em segundos.

Mas por trás dos bastidores existe uma verdadeira cadeia industrial de processamento.

O aplicativo envia a solicitação.

Uma API recebe o pedido.

Serviços de autenticação validam identidade.

Motores antifraude executam verificações.

Regras de compliance são avaliadas.

Sistemas de limites são consultados.

Dados cadastrais são verificados.

Mensagerias distribuem eventos.

Sistemas contábeis registram a operação.

Mecanismos de liquidação realizam o acerto financeiro.

Tudo isso antes que a mensagem "PIX realizado com sucesso" apareça na tela.

O usuário vê um clique.

O datacenter vê centenas de transações.


Onde entra o mainframe?

É aqui que muita gente se surpreende.

O mainframe raramente aparece na camada visual.

Ele normalmente opera na camada mais importante.

A camada onde não pode haver erro.

Imagine o seguinte cenário.

Se uma rede social ficar indisponível por 10 minutos, usuários reclamam.

Se um streaming cair durante uma série, pessoas ficam irritadas.

Mas se um banco perder o controle de saldos durante 10 minutos?

O problema pode atingir milhões de clientes.

Por isso os sistemas responsáveis pelos registros financeiros mais críticos precisam apresentar:

  • disponibilidade extrema;

  • consistência absoluta;

  • segurança rigorosa;

  • rastreabilidade completa;

  • recuperação imediata.

São justamente essas características que fizeram os mainframes permanecerem relevantes.


O paradoxo da fintech

As fintechs surgiram prometendo romper com os bancos tradicionais.

Em muitos aspectos conseguiram.

Mudaram a experiência do cliente.

Reduziram burocracias.

Popularizaram contas digitais.

Criaram novos modelos de negócio.

Mas descobriram rapidamente uma verdade do mercado financeiro.

Movimentar dinheiro é muito mais difícil do que movimentar dados.

Enviar uma foto errada em uma rede social gera um transtorno.

Transferir R$ 10 milhões para a conta errada gera uma crise.

Por isso a arquitetura financeira moderna acabou evoluindo para um modelo híbrido.

Na superfície:

  • cloud;

  • APIs;

  • microsserviços;

  • inteligência artificial.

No núcleo:

  • processamento transacional;

  • bancos de dados críticos;

  • mensageria corporativa;

  • sistemas centrais de liquidação.

É uma combinação extremamente poderosa.


A nuvem descobriu que precisa do mainframe

Durante alguns anos surgiu uma narrativa bastante agressiva.

Muitos especialistas afirmavam que o mainframe desapareceria rapidamente.

A computação em nuvem seria suficiente para tudo.

A realidade mostrou algo diferente.

O que ocorreu foi integração.

Hoje observamos ambientes híbridos onde:

  • Kubernetes conversa com CICS;

  • APIs REST acessam programas COBOL;

  • aplicações cloud consomem serviços do z/OS;

  • eventos trafegam através do IBM MQ;

  • microsserviços utilizam informações armazenadas em DB2.

Não houve substituição.

Houve convergência.

A nuvem não matou o mainframe.

A nuvem passou a conversar com ele.


O caso brasileiro

O Brasil possui um dos sistemas financeiros mais sofisticados do planeta.

Muitas vezes não percebemos isso.

PIX.

TED.

DOC.

Open Finance.

Cartões.

Boletos.

Débito automático.

Tudo isso precisa funcionar para centenas de milhões de contas.

Os números impressionam.

Bilhões de transações são processadas todos os meses.

Milhões de operações acontecem simultaneamente.

O sistema precisa funcionar:

  • de madrugada;

  • em feriados;

  • durante promoções;

  • na Black Friday;

  • durante a Copa do Mundo;

  • durante grandes eventos nacionais.

A infraestrutura necessária para suportar esse volume é gigantesca.

E boa parte dela continua baseada em tecnologias que nasceram décadas atrás, mas evoluíram continuamente.


O COBOL que ninguém vê

Poucas tecnologias sofreram tanto preconceito quanto o COBOL.

Para muitos profissionais jovens, COBOL parece uma relíquia.

Algo pertencente a museus de informática.

Mas existe um detalhe curioso.

Grande parte das pessoas que criticam COBOL utilizou sistemas processados por COBOL antes mesmo do café da manhã.

Salário.

PIX.

Cartão.

Financiamento.

Previdência.

Seguros.

Consórcios.

Tudo isso frequentemente passa por programas COBOL.

O motivo é simples.

Esses sistemas foram construídos ao longo de décadas.

Receberam investimentos bilionários.

Foram testados em condições extremas.

Acumularam conhecimento de negócio impossível de reproduzir rapidamente.

Muitas vezes o código representa mais valor do que a própria infraestrutura.


O banco invisível

Imagine um iceberg.

O cliente vê apenas a ponta.

Aplicativo.

Cartão.

Notificação.

Interface.

Mas abaixo da superfície existe uma massa gigantesca de tecnologia invisível.

Essa parte inclui:

  • motores contábeis;

  • sistemas regulatórios;

  • integração com Banco Central;

  • mecanismos de liquidação;

  • auditoria;

  • compliance;

  • segurança.

É nesse universo invisível que o mainframe continua brilhando.

E justamente por ser invisível, raramente recebe o reconhecimento merecido.


Quando tudo funciona ninguém percebe

Existe uma ironia interessante no mundo da infraestrutura.

Quanto melhor um sistema funciona, menos as pessoas falam sobre ele.

Ninguém elogia um elevador por funcionar.

Ninguém agradece à rede elétrica por fornecer energia.

Ninguém faz uma postagem comemorando que o saldo bancário apareceu corretamente.

Mas quando ocorre uma falha?

Todo mundo percebe.

Por isso os sistemas centrais são projetados para uma missão simples:

não chamar atenção.

O sucesso é a invisibilidade.


O futuro não é cloud versus mainframe

Uma das maiores lições da última década foi perceber que a discussão estava errada.

A pergunta nunca deveria ter sido:

"Cloud ou Mainframe?"

A pergunta correta é:

"Como integrar os dois da melhor forma possível?"

Os líderes do mercado entenderam isso.

Hoje as arquiteturas mais modernas utilizam o melhor dos dois mundos.

Cloud para:

  • inovação rápida;

  • elasticidade;

  • analytics;

  • inteligência artificial.

Mainframe para:

  • processamento massivo;

  • transações críticas;

  • consistência financeira;

  • segurança corporativa.

O resultado é uma arquitetura híbrida extremamente eficiente.


A verdadeira transformação digital

Muitas empresas acreditam que transformação digital significa abandonar tudo que veio antes.

Mas a história mostra outra coisa.

Transformação digital bem-sucedida raramente consiste em destruir.

Consiste em evoluir.

Os sistemas que sustentam o mercado financeiro brasileiro representam décadas de conhecimento acumulado.

Substituí-los completamente seria como demolir uma usina hidrelétrica para construir um gerador portátil.

Não faz sentido.

O caminho inteligente é modernizar.

Expor APIs.

Integrar plataformas.

Automatizar processos.

Conectar o legado ao futuro.


O que os estudantes precisam entender

Quem está começando carreira em tecnologia frequentemente busca apenas as ferramentas mais recentes.

Isso é natural.

Mas existe uma lição valiosa.

As tecnologias que movimentam bilhões nem sempre são as mais populares nas redes sociais.

Muitas vezes são as mais confiáveis.

As mais estáveis.

As mais resilientes.

O profissional que entende:

  • cloud;

  • APIs;

  • Kubernetes;

  • segurança;

  • mainframe;

  • integração corporativa;

torna-se extremamente valioso para o mercado.

Porque consegue enxergar a arquitetura completa.

Não apenas a camada visível.


Conclusão: o coração continua batendo

Os maiores bancos digitais do Brasil nasceram na nuvem.

Foram criados por uma geração que cresceu falando de APIs, microsserviços e aplicações móveis.

Mudaram completamente a forma como os brasileiros se relacionam com o dinheiro.

Mas, ao crescerem, descobriram algo que os bancos tradicionais já sabiam há décadas.

No mercado financeiro, velocidade é importante.

Experiência do usuário é importante.

Inovação é importante.

Mas nada é mais importante do que confiança.

E confiança se constrói com sistemas capazes de operar dia após dia, ano após ano, movimentando bilhões de reais sem perder o controle de um único centavo.

Por isso, enquanto milhões de brasileiros fazem PIX, pagam boletos, investem, financiam imóveis e utilizam aplicativos modernos, existe uma infraestrutura silenciosa trabalhando nos bastidores.

Uma infraestrutura que raramente aparece nas propagandas.

Que quase nunca vira manchete.

Mas que continua sustentando o sistema financeiro nacional.

A nuvem trouxe inovação.

As fintechs trouxeram agilidade.

Os aplicativos trouxeram conveniência.

Mas, no coração de boa parte dessa engrenagem, o velho gigante continua trabalhando.

Discreto.

Confiável.

Resiliente.

Processando bilhões.

Como faz há décadas.

E, ao que tudo indica, continuará fazendo por muitos anos.


sexta-feira, 11 de outubro de 2024

JSON em COBOL no IBM Z: O Holocron das APIs Modernas – JSON GENERATE - Parte III

 

Bellacosa Mainframe e o json em cobol parte iii

JSON em COBOL no IBM Z: O Holocron das APIs Modernas

Parte 3 – JSON GENERATE

Quando o Padawan Aprende a Construir APIs REST com COBOL e Descobre que Também Pode Falar com a Galáxia

Por Bellacosa Mainframe


"JSON PARSE ensina COBOL a escutar. JSON GENERATE ensina COBOL a responder. Um Mestre Jedi precisa dominar ambos."

Mestre Bellacosa Sysprog Jedi


Introdução

Nas jornadas anteriores, o jovem Padawan descobriu algo extraordinário.

Primeiro aprendeu que COBOL moderno fala JSON.

Depois aprendeu a utilizar JSON PARSE.

Agora chega o momento em que ele percebe uma verdade ainda mais impressionante.

COBOL não apenas entende JSON.

COBOL também consegue produzir JSON de forma elegante, otimizada e extremamente rápida.

E isso é feito através de uma instrução quase tão poderosa quanto um sabre de luz recém-montado.

JSON GENERATE


O que é JSON GENERATE?

JSON GENERATE é um serializador.

Seu objetivo é simples.

Transformar estruturas COBOL em texto JSON.

Visualmente.

WORKING STORAGE


↓

JSON GENERATE


↓

JSON


↓

REST API


↓

Aplicativo


↓

Microsserviço

Em outras palavras.

Ele faz exatamente o oposto de JSON PARSE.


Antes do Enterprise COBOL 6

A vida era difícil.

Muitos sistemas faziam:

STRING

"{"

'"id":'

WS-ID

','
'"nome":"'

WS-NOME

'"'

"}"

INTO WS-BUFFER

Problemas.

Vírgulas.

Aspas.

Espaços.

Campos vazios.

Arrays.

Escape.

Tudo manual.


Padawan sofria.


O nascimento de JSON GENERATE

Enterprise COBOL Version 6.

Introduziu.

JSON GENERATE.


Mudou completamente.

Integrações.


Hoje.

Muito utilizado.

6.3

6.4

6.5


Primeiro exemplo

Passo 1

Estrutura COBOL

01 WS-CLIENTE.


05 WS-ID.
PIC 9(5).


05 WS-NOME.
PIC X(30).


05 WS-IDADE.
PIC 999.

Passo 2

JSON Buffer

01 WS-JSON.

PIC X(500).

Passo 3

Popular

MOVE 100

TO WS-ID


MOVE 'Bellacosa'

TO WS-NOME


MOVE 52

TO WS-IDADE

Passo 4

Gerar

JSON GENERATE

WS-JSON


FROM WS-CLIENTE

Passo 5

Display

DISPLAY WS-JSON

Resultado.

{

"id":100,

"nome":"Bellacosa",

"idade":52

}

Pronto.

API pronta.


Como funciona internamente?

Compilador gera.

Serializer.


Percorre.

Estrutura.

Campo.

Por campo.


Converte.

Numéricos.

Strings.

Booleans.

Occurs.


Escreve.

JSON.


Visualmente.

WS-ID


↓

Serializer


↓

"id":100

Memória

JSON continua sendo.

Texto.


Exemplo.

01 WS-JSON.

PIC X(10000).

Buffer.

Grande.


Serializer.

Preenche.


Pouco overhead.


Muito eficiente.


Campos vazios

Problema comum.


Exemplo.

MOVE SPACES

TO WS-NOME

Resultado.

"name":""

Nem sempre desejado.


SUPPRESS

Ferramenta poderosa.


Exemplo conceitual.

JSON GENERATE

WS-JSON


FROM WS-DADOS


SUPPRESS

Campos vazios.

Não aparecem.


Muito usado.

Em APIs.


OMITTED

Outra técnica.


Campo opcional.


Excelente.

Open Banking.

PIX.


NAME OF

Talvez a funcionalidade favorita.

Do Bellacosa.


COBOL.

05 WS-NOME.

JSON desejado.

"customerName"

NAME OF permite.

Mapear.


Muito elegante.


Exemplo API PIX

COBOL.

01 PIX.


05 CHAVE.


05 VALOR.


05 DATA.

JSON.

{

"chave":"abc",


"valor":100,


"data":"2026-06-25"

}

JSON GENERATE.

Faz.

Tudo.


Arrays

Muito útil.


COBOL.

05 TELEFONES.


10 TEL OCCURS 5.

JSON.

"telefones":[


"1111",


"2222"

]

Automático.


Objetos aninhados

COBOL.

01 CLIENTE.


05 DADOS.


10 ID.


10 NOME.



05 ENDERECO.


10 CIDADE.


10 CEP.

Resultado.

{

"cliente":{


"id":1,

"nome":"Bellacosa"


},

"endereco":{


"cidade":"SP"

}

}

Muito elegante.


Null

JSON suporta.


COBOL não.


Precisamos.

Decidir.


Campo vazio.


Campo omitido.


Valor padrão.


Muito importante.


UTF8

Outro cuidado.


JSON.

UTF8.


COBOL.

EBCDIC.


Conversão.

Necessária.


Especialmente.

Acentos.


José.

São Paulo.


Ç.

Ã.


Sempre testar.


Segurança

Poucos lembram.


JSON GENERATE.

Também possui.

Riscos.


Exemplo.

Dados internos.


Senha.


CPF.


Token.


Acidentalmente.

Expostos.


Exemplo.

01 CLIENTE.


05 SENHA.


PIC X(20).

JSON GENERATE.

Sem SUPPRESS.


API.

Expõe.

Senha.


Muito perigoso.


Boa prática

Criar.

Estrutura.

Específica.

API.


Nunca.

Gerar.

Diretamente.

Working Storage.

Inteira.


Pretty JSON

COBOL.

Não gera.

JSON bonito.


Compacto.


Mais eficiente.


Consumidor.

Pode formatar.


Performance

Excelente.


Serializer.

Nativo.


Compilado.


Muito rápido.


Melhor.

Que STRING.


Melhor.

Que montar.

Na mão.


Benchmark aproximado

Manual.

100%


JSON GENERATE.

Muito menor.

CPU.


Menos bugs.


Mais manutenção.


Curiosidade

Muitos aplicativos bancários.

Recebem.

JSON.

Gerado.

Por COBOL.


Usuário.

Nunca percebe.


Abre app.


Consulta saldo.


Recebe.

JSON.


Origem.

COBOL.

No z17.


APIs modernas

JSON GENERATE é usado.

Em.

z/OS Connect

CICS

Liberty

MQ

Kafka

OpenShift

Cloud Pak


Praticamente.

Todo lugar.


Bellacosa Best Practices

Sempre

Criar DTO.

Separado.


Sempre

Usar SUPPRESS.


Sempre

Validar UTF8.


Sempre

Versionar JSON.


Sempre

Documentar.

Swagger.

OpenAPI.


Nunca

Expor.

Campos internos.


Nunca

Montar.

JSON.

Na mão.

Com STRING.


Comparação

TécnicaRecomendada
STRINGNão
UNSTRINGNão
INSPECTNão
Parser próprioEvitar
JSON GENERATESim
JSON PARSESim

O Conselho do Mestre Bellacosa

Durante muitos anos, o programador COBOL era visto como alguém responsável apenas por arquivos sequenciais, relatórios batch e transações CICS.

JSON GENERATE mudou essa percepção.

Ele permitiu que sistemas escritos décadas atrás começassem a responder chamadas REST, conversar com aplicativos móveis, participar do Open Finance e integrar-se naturalmente a arquiteturas modernas baseadas em APIs.

Talvez essa seja uma das maiores virtudes do Enterprise COBOL.

Ele não exige que o desenvolvedor abandone tudo aquilo que aprendeu.

Ele simplesmente acrescenta novas habilidades.

E diz ao Padawan:

Continue usando seus níveis 01, 05 e 10.

Continue escrevendo programas robustos.

Continue confiando na estabilidade do IBM Z.

Eu apenas ensinarei seu código a responder em uma linguagem compreendida por praticamente toda a galáxia digital.


Continua na Parte 4

JSON Jedi Master – z/OS Connect, MQ, Kafka, OpenShift, APIs de Alto Desempenho, Segurança OWASP e Técnicas Avançadas para o Mestre Bellacosa do IBM Z.

domingo, 18 de agosto de 2024

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.


Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988
GitHub LinkedIn
Inicializando conteúdo...