 |
| Bellacosa Mainframe e o ocaso do Banco Ueno no Paraguay |
☕ UM CAFÉ NO BELLACOSA MAINFRAME
🎩 O GOLPE DE MESTRE DOS BANCOS DIGITAIS: THOMAS CROWN, UENO BANK, BANCO MASTER E OS MILHÕES QUE DESAPARECERAM ATRÁS DOS SISTEMAS!
Quando um banco possui milhões de clientes, computadores sofisticados, inteligência artificial, bilhões em operações e uma contabilidade aparentemente impecável, quem garante que o dinheiro realmente existe? Sob a ótica de Thomas Crown, vamos investigar dois escândalos financeiros sul-americanos e descobrir como COBOL, IBM Z, RACF, CICS, Db2, auditoria e controles independentes podem impedir que uma bela arquitetura tecnológica esconda uma perigosa realidade financeira.
Bellacosa Mainframe — Arqueologia da Computação, COBOL, Segurança Bancária, Inteligência Artificial e os Fantasmas da Contabilidade Digital.
🎬 Prólogo — Thomas Crown entra no banco e percebe que o quadro mais valioso não está na parede
Nova York, 1999.
Um homem elegantemente vestido entra num museu de arte.
Seu nome é Thomas Crown.
Milionário, sofisticado, inteligente, amante de desafios e absolutamente convencido de que qualquer sistema de segurança possui uma fraqueza.
Crown não está particularmente interessado no dinheiro. Ele já possui muito mais do que necessita.
O que o fascina é a possibilidade de superar um sistema considerado invulnerável.
No filme The Thomas Crown Affair, dirigido por John McTiernan e estrelado por Pierce Brosnan e Rene Russo, Crown organiza o roubo de uma valiosa pintura de Claude Monet.
Mas existe um detalhe extraordinário.
O golpe não depende simplesmente de desativar alarmes, arrombar portas ou derrotar vigilantes.
O verdadeiro truque consiste em manipular aquilo que os responsáveis pela segurança acreditam estar enxergando.
É exatamente essa ideia que nos interessa.
Imagine agora que Thomas Crown abandona temporariamente os museus de Nova York e viaja para Assunção, no Paraguai.
Diante dele aparece um banco digital com milhões de clientes, aplicativos modernos, biometria, computação em nuvem e sistemas capazes de processar um volume gigantesco de transações.
Pouco depois, ele encontra outro caso, desta vez no Brasil.
O Banco Master.
Dois escândalos financeiros. Dois contextos diferentes. Muitas perguntas semelhantes.
Crown observa os números, examina as operações e pergunta:
De que adianta proteger perfeitamente uma pintura se ninguém verifica se a pintura é verdadeira?
No mundo bancário, a pergunta seria:
De que adianta um computador calcular corretamente bilhões de dólares se os ativos utilizados no cálculo não possuem o valor declarado?
Prepare o café. Nossa investigação começa agora.
Nota editorial: Thomas Crown é utilizado como personagem e recurso narrativo fictício. As investigações envolvendo os bancos são fatos reais, mas suspeitas e acusações não devem ser confundidas com condenações definitivas.
🎩 Capítulo I — Quem é Thomas Crown e o que ele tem a ensinar sobre segurança bancária?
Thomas Crown representa um tipo particular de adversário: aquele que compreende as regras, estuda os comportamentos e procura explorar aquilo que os responsáveis pela segurança não questionam.
No filme de 1999, sua adversária é Catherine Banning, uma investigadora de seguros interpretada por Rene Russo.
Catherine compreende algo que muitos especialistas em segurança esquecem: investigar não significa apenas examinar o mecanismo de proteção.
É necessário compreender os incentivos, os interesses e as relações entre as pessoas.
Nos bancos, acontece exatamente a mesma coisa.
Um sistema pode possuir:
Criptografia de última geração.
Autenticação multifator.
Monitoramento permanente.
Servidores redundantes.
Processamento transacional confiável.
Recuperação automática de falhas.
Auditoria eletrônica.
Mesmo assim, a instituição pode enfrentar problemas graves de governança financeira.
Por quê?
Porque sistemas verificam condições definidas por pessoas.
Se uma regra permite que determinada autoridade aprove empréstimos acima dos limites adequados, o computador poderá executar essa autorização perfeitamente.
Se uma empresa vinculada ao controlador não estiver corretamente identificada no cadastro, um algoritmo poderá classificá-la como cliente independente.
Se uma carteira de créditos possuir registros contabilmente consistentes, mas não houver comprovação da existência dos contratos, o balanço poderá apresentar números aparentemente corretos.
A primeira lição de Thomas Crown é simples:
Nunca confunda a aparência de controle com a existência de controle efetivo.
🏦 Capítulo II — Ueno Bank: a ascensão de um gigante digital paraguaio
O Ueno Bank tornou-se um dos exemplos mais conhecidos da expansão bancária digital no Paraguai.
Sua estratégia combinava serviços financeiros acessíveis, abertura digital de contas, cartões, pagamentos eletrônicos e uma presença comercial apoiada em tecnologia.
A instituição cresceu rapidamente e passou a atender aproximadamente três milhões de clientes.
O que torna esse número extraordinário é a dimensão do mercado paraguaio.
Uma instituição com essa quantidade de usuários deixa de ser apenas uma empresa financeira inovadora. Ela passa a integrar o cotidiano econômico de uma parcela muito significativa da população.
Pequenos comerciantes recebem pagamentos.
Trabalhadores movimentam salários.
Famílias mantêm economias.
Empresas contratam crédito.
Órgãos públicos depositam recursos.
E aqui encontramos uma curiosidade importante.
Um banco digital pode crescer comercialmente muito mais depressa do que uma instituição tradicional.
Não precisa abrir centenas de agências para conquistar novos correntistas.
Seu aplicativo funciona como uma agência disponível permanentemente.
Entretanto, o crescimento das operações precisa ser acompanhado por capital, liquidez, controles internos e capacidade de administração de riscos.
Foi justamente a fragilidade dessa relação que se tornou central no caso Ueno.
Em 2 de novembro de 2026, o Banco Central do Paraguai decidiu iniciar o procedimento de resolução da instituição, anunciado publicamente no dia seguinte.
Segundo o regulador, ajustes realizados nos demonstrativos financeiros durante o processo de regularização revelaram que o índice de solvência havia caído para menos de 50% do mínimo exigido.
Isso não significa simplesmente que o banco ficou sem dinheiro em determinada conta.
Significa que sua capacidade patrimonial de suportar os riscos assumidos estava gravemente comprometida.
A autoridade determinou medidas para preservar ativos, apurar a situação patrimonial e proteger depositantes.
A dimensão social do episódio foi enorme, especialmente diante da presença de depósitos públicos e recursos relacionados à previdência social.
A história demonstra que um banco pode possuir uma experiência digital moderna e, simultaneamente, enfrentar problemas gravíssimos em sua estrutura financeira.
A tecnologia facilita o acesso ao banco.
Mas não substitui capital verdadeiro.
💰 Capítulo III — Banco Master: quando o problema atravessa a fronteira
Agora Thomas Crown chega ao Brasil.
Sua atenção se volta ao Banco Master.
A instituição brasileira apresentou uma expansão significativa e chamou a atenção do mercado por seu modelo de captação, operações financeiras e exposição a ativos de maior risco.
Em 18 de novembro de 2025, o Banco Central do Brasil decretou a liquidação extrajudicial de instituições do conglomerado Master.
A autoridade apontou grave crise de liquidez, comprometimento significativo da situação econômico-financeira e graves violações das normas aplicáveis.
Um dos aspectos centrais da investigação brasileira envolve a comercialização de carteiras de crédito para o Banco de Brasília, o BRB.
A Polícia Federal passou a investigar operações associadas a aproximadamente R$ 12,2 bilhões em créditos suspeitos.
Aqui encontramos uma semelhança importante com o escândalo paraguaio.
Nos dois casos, surgiram questionamentos sobre a qualidade dos ativos, a consistência das informações financeiras e a efetividade dos controles.
Entretanto, os mecanismos investigados não são necessariamente idênticos.
No Master, uma das suspeitas centrais envolve créditos sem lastro adequado ou inexistentes.
No Ueno, documentos e manifestações públicas apontaram problemas relacionados a operações com empresas vinculadas, qualidade dos ativos, documentação e ajustes contábeis.
Isso nos conduz à segunda lição de Thomas Crown:
Dois quadros podem parecer iguais na parede, mas apenas a investigação de sua origem permite determinar se ambos são autênticos.
No universo bancário, isso significa verificar cada contrato, cada garantia, cada contraparte e cada obrigação financeira.
🧠 Capítulo IV — O maior truque não está no aplicativo: está nos dados
Vamos imaginar um banco fictício chamado Crown Digital.
A instituição possui cem mil contratos de crédito.
Seu sistema registra:
| Informação | Valor |
|---|---|
| Quantidade de contratos | 100.000 |
| Valor total contabilizado | R$ 5 bilhões |
| Parcelas recebidas no mês | R$ 120 milhões |
| Créditos considerados regulares | 95% |
| Créditos em atraso | 5% |
O painel de controle apresenta uma bonita mensagem verde:
SISTEMA OPERACIONAL — PROCESSAMENTO CONCLUÍDO COM SUCESSO.
Mas Catherine Banning resolve investigar.
Ela seleciona uma amostra de mil contratos.
Descobre que alguns clientes não reconhecem as operações.
Outros contratos apresentam garantias não comprovadas.
Algumas empresas pertencem ao mesmo grupo econômico.
E determinados pagamentos foram realizados com recursos obtidos em novos financiamentos.
O sistema funcionou.
O problema estava na realidade econômica representada pelos registros.
É o conhecido princípio da computação:
Garbage In, Garbage Out — lixo entra, lixo sai.
Mas existe uma segunda dimensão, ainda mais perigosa.
Quando registros inválidos circulam por diferentes sistemas, a repetição pode produzir uma falsa sensação de autenticidade.
O mesmo contrato aparece no core bancário, no relatório contábil, no painel de riscos e no arquivo enviado ao regulador.
Quatro sistemas concordam.
Isso não significa necessariamente que quatro verificações independentes tenham ocorrido.
Pode significar apenas que quatro sistemas copiaram a mesma informação original.
Eis uma lição que vale ouro para qualquer programador COBOL.
Conciliação entre sistemas não é o mesmo que comprovação independente da existência de um ativo.
☁️ Capítulo V — Oracle, AWS e o verdadeiro CPD do Ueno
Thomas Crown gosta de tecnologia.
Por isso, antes de investigar os números, ele examina a infraestrutura.
O Ueno divulgou uma migração de seu core bancário para Oracle Cloud Infrastructure, realizada com a participação da empresa itti.
A documentação institucional identifica o uso do Oracle Exadata Database Service on Dedicated Infrastructure.
Essa arquitetura oferece recursos especializados para processamento de bancos de dados de alto desempenho.
Também encontramos documentação pública da fabricante KAL sobre a infraestrutura dos terminais de autoatendimento utilizados pelo Ueno.
Entre as soluções divulgadas estão:
K3A, aplicação dos terminais.
KTC, ferramenta de monitoramento e gerenciamento.
KTH, sistema de processamento de operações relacionadas aos caixas.
Kalignite, plataforma de software para autoatendimento.
Outras informações públicas mencionam serviços de nuvem e ferramentas de automação integradas ao ecossistema bancário.
Mas existe um cuidado fundamental: não dispomos de um inventário integral e auditado dos servidores, sistemas operacionais, equipamentos de rede, versões de software e dependências de produção da instituição.
Portanto, não podemos afirmar que determinada falha de produto tenha causado a crise.
Também não encontramos evidência pública suficiente para afirmar que o Ueno utilizava IBM Z, z/OS, COBOL ou CICS em seu core.
É importante separar três perguntas:
A tecnologia funcionava?
Os dados processados representavam operações legítimas?
Os administradores utilizavam adequadamente as informações produzidas?
São questões diferentes.
Um banco pode responder positivamente à primeira e negativamente às outras duas.
A computação em nuvem permite escalar operações e melhorar a disponibilidade.
Mas nem Oracle, AWS, IBM ou qualquer fabricante pode garantir, apenas por fornecer tecnologia, a honestidade de cada registro financeiro.
🖼️ Capítulo VI — O quadro de US$ 127 milhões: quando software vira patrimônio
Este é um dos capítulos mais interessantes da investigação.
Em agosto de 2026, o jornal paraguaio ABC Color publicou informações sobre uma rubrica contábil do Ueno identificada como Bens Intangíveis — Sistemas.
O saldo líquido informado no encerramento de 2025 era de aproximadamente 761,4 bilhões de guaranis, equivalentes, segundo a reportagem, a cerca de US$ 127 milhões.
O montante chamou atenção por superar significativamente os registros comparáveis de outras instituições paraguaias.
Mas por que um banco contabilizaria software como patrimônio?
Porque, sob determinadas condições contábeis, investimentos em desenvolvimento e aquisição de sistemas podem constituir ativos intangíveis.
Imagine que uma instituição desenvolva uma plataforma bancária por R$ 20 milhões.
Se os requisitos contábeis aplicáveis forem atendidos, parte desses custos poderá ser reconhecida como ativo e amortizada durante sua vida útil.
Isso é diferente de registrar todas as despesas tecnológicas como gastos imediatos.
O problema surge quando despesas que deveriam ser reconhecidas no resultado são indevidamente capitalizadas ou quando o valor atribuído ao ativo não encontra suporte econômico suficiente.
Um contrato de manutenção recorrente, por exemplo, não se transforma automaticamente em ativo intangível simplesmente porque está relacionado à tecnologia.
Também é necessário distinguir propriedade intelectual, licenças, serviços de nuvem, equipamentos físicos e contratos antecipados.
No caso Ueno, a imprensa questionou a composição e classificação de determinadas rubricas.
A instituição apresentou explicações defendendo a abrangência de seus investimentos tecnológicos.
Esses questionamentos não demonstram, isoladamente, que cada lançamento fosse irregular.
A conclusão depende de documentação contratual, critérios contábeis, comprovação de entregas e revisão independente.
Thomas Crown observaria que um quadro pode estar segurado por cem milhões de dólares.
Mas o valor declarado não substitui a necessidade de determinar sua autenticidade.
No balanço bancário, o preço de um software não comprova automaticamente seu valor econômico recuperável.
💻 Capítulo VII — Laboratório COBOL: construindo o primeiro detector de operações suspeitas
Agora vamos entrar no laboratório Bellacosa Mainframe.
Nosso objetivo será construir um pequeno programa COBOL educativo que analise operações de crédito.
Ele não determina se ocorreu fraude.
Ele apenas identifica situações que exigem revisão humana.
Vamos trabalhar com quatro informações:
Valor solicitado.
Limite permitido para a operação.
Existência de vínculo com o grupo controlador.
Situação da documentação.
A regra será simples.
Uma operação deve ser encaminhada para revisão quando superar o limite, envolver parte relacionada ou apresentar documentação incompleta.
Passo 1 — Criar o programa
No ambiente IBM Z, utilizando Enterprise COBOL, crie um membro chamado CRNRISCO numa biblioteca de fontes.
O exemplo também pode ser adaptado a um ambiente de aprendizagem com GnuCOBOL.
>>SOURCE FORMAT FREE
identification division.
program-id. CRNRISCO.
environment division.
data division.
working-storage section.
01 ws-valor pic 9(9)v99.
01 ws-limite pic 9(9)v99.
01 ws-relacionada pic x.
01 ws-documentacao pic x.
01 ws-alerta pic x value 'N'.
procedure division.
move 50000000.00 to ws-valor
move 10000000.00 to ws-limite
move 'S' to ws-relacionada
move 'N' to ws-documentacao
display "BELLACOSA MAINFRAME"
display "CONTROLE DE OPERACOES"
if ws-valor > ws-limite
display "ALERTA: LIMITE EXCEDIDO"
move 'S' to ws-alerta
end-if
if ws-relacionada = 'S'
display "ALERTA: PARTE RELACIONADA"
move 'S' to ws-alerta
end-if
if ws-documentacao not = 'S'
display "ALERTA: DOCUMENTOS PENDENTES"
move 'S' to ws-alerta
end-if
if ws-alerta = 'S'
display "STATUS: REVISAO OBRIGATORIA"
else
display "STATUS: TRIAGEM SEM ALERTAS"
end-if
goback.Passo 2 — Entender o programa
A IDENTIFICATION DIVISION identifica o programa.
A DATA DIVISION define as variáveis.
O campo WS-VALOR armazena o valor da operação com duas casas decimais.
O campo WS-LIMITE representa um limite autorizado.
A variável WS-RELACIONADA indica se existe relação societária conhecida com o grupo controlador.
O campo WS-DOCUMENTACAO informa se os documentos necessários estão completos.
Finalmente, WS-ALERTA registra se alguma condição de risco foi identificada.
Observe um detalhe importante.
O programa não aprova automaticamente o empréstimo quando não encontra alertas.
Ele apenas informa que a triagem inicial não identificou nenhuma das condições programadas.
Isso é fundamental.
Ausência de alerta não significa ausência de risco.
Passo 3 — Executar o teste
Com os valores preenchidos, o resultado esperado será:
BELLACOSA MAINFRAME
CONTROLE DE OPERACOES
ALERTA: LIMITE EXCEDIDO
ALERTA: PARTE RELACIONADA
ALERTA: DOCUMENTOS PENDENTES
STATUS: REVISAO OBRIGATORIATrês problemas foram identificados.
O empréstimo supera o limite.
A operação envolve uma parte relacionada.
A documentação está incompleta.
Na arquitetura de produção de um banco, a transação deveria ser submetida a controles adicionais antes de qualquer liberação.
Passo 4 — Realizar novos testes
Modifique os valores.
Primeiro, experimente uma operação de R$ 100 mil, com limite de R$ 500 mil, sem relação societária identificada e com documentos completos.
O sistema deverá informar que não encontrou alertas nessa triagem.
Depois, experimente uma operação de R$ 100 mil envolvendo uma empresa relacionada.
Mesmo abaixo do limite, o programa deverá exigir revisão.
Esse segundo teste é especialmente importante.
O tamanho de uma operação não determina sozinho seu risco.
Passo 5 — Entender as limitações
Nosso programa é apenas um exercício.
Um sistema bancário real também precisaria verificar beneficiários finais, garantias, exposições consolidadas, capacidade de pagamento, classificação de risco, limites regulatórios e histórico das contrapartes.
Além disso, os dados precisam vir de fontes confiáveis, e o bloqueio deve ser imposto por um componente transacional que não possa ser contornado simplesmente alterando uma interface.
E o código jamais deveria ser colocado em produção sem testes, revisão, tratamento de erros, segregação de funções e aprovação formal.
🛡️ Capítulo VIII — RACF: quem possui as chaves do museu?
No filme, Thomas Crown conhece a importância do acesso.
Uma porta protegida não serve para muita coisa quando alguém possui a chave correta e pode utilizá-la sem fiscalização.
No IBM Z, o RACF pode participar da proteção de recursos, identidades e permissões.
Mas uma autorização técnica não equivale necessariamente a uma autorização financeira legítima.
Imagine um executivo responsável por conceder empréstimos.
Ele não deveria conseguir, sozinho, cadastrar uma empresa, registrar seus beneficiários, estabelecer o limite de crédito, aprovar a operação, liberar os recursos e alterar posteriormente os registros de auditoria.
Essas atividades precisam ser segregadas.
A separação de funções é uma das defesas clássicas contra fraudes internas.
Uma arquitetura adequada poderia estabelecer perfis independentes para cadastro, análise de risco, aprovação, operações, contabilidade e auditoria.
O RACF controlaria o acesso aos recursos técnicos sob sua responsabilidade.
A aplicação COBOL, por sua vez, aplicaria as regras específicas do negócio.
O processo de governança definiria quem pode autorizar exceções.
E a auditoria independente verificaria se as regras foram respeitadas.
Outro ponto importante é o gerenciamento de identidades privilegiadas.
Um administrador técnico pode necessitar de acesso emergencial.
Isso não significa que esse acesso deva permanecer permanentemente liberado.
O ideal é utilizar privilégios temporários, aprovações apropriadas, registro das ações e revisão posterior.
Thomas Crown não precisaria derrotar todas as fechaduras do museu se pudesse convencer alguém a entregar a chave principal.
🗄️ Capítulo IX — Db2 e CICS: o coração das transações
Vamos imaginar um ambiente bancário IBM Z.
O aplicativo móvel envia uma solicitação de empréstimo através de uma API.
A requisição chega a uma transação CICS.
Um programa COBOL valida os dados e consulta informações armazenadas no Db2.
Esse programa precisa verificar não apenas a existência do cliente, mas também suas relações econômicas.
Uma estrutura simplificada poderia conter três conjuntos de informações.
A primeira tabela armazena os clientes.
A segunda registra contratos de crédito.
A terceira contém relações entre clientes, empresas e grupos econômicos.
Uma consulta educativa poderia procurar operações relacionadas a determinados grupos:
SELECT C.ID_CONTRATO,
C.ID_CLIENTE,
C.VALOR_CREDITO,
R.ID_GRUPO
FROM CONTRATOS C
JOIN RELACOES R
ON C.ID_CLIENTE = R.ID_CLIENTE
WHERE C.VALOR_CREDITO > 10000000;É apenas um exemplo conceitual.
Num ambiente real, seria necessário considerar a data de validade das relações societárias, múltiplos beneficiários, percentuais de participação, garantias e regras regulatórias.
Uma consulta SQL correta não consegue descobrir automaticamente um vínculo societário que nunca foi registrado.
Esse é um dos grandes desafios dos bancos.
Uma empresa pode aparecer com nome diferente, utilizar intermediários ou participar de diversas estruturas jurídicas.
Por isso, um mecanismo de identificação de partes relacionadas precisa de fontes adicionais e processos de atualização.
O Db2 é excelente para armazenar e consultar dados.
Mas a capacidade de descobrir relações econômicas depende da qualidade do modelo de dados e das informações disponíveis.
A arquitetura também precisa garantir atomicidade das operações.
Se um empréstimo for aprovado, mas o registro da exposição consolidada não for atualizado, o banco poderá ficar com informações inconsistentes.
As transações devem manter integridade, inclusive diante de falhas ou operações simultâneas.
É aqui que mecanismos transacionais associados a CICS, COBOL e Db2 se tornam especialmente valiosos.
🎭 Capítulo X — O truque das empresas relacionadas
Imagine três empresas fictícias:
Crown Tecnologia.
Crown Participações.
Crown Investimentos.
Formalmente, possuem registros empresariais distintos.
Mas todas pertencem ao mesmo grupo econômico.
Agora imagine que cada uma solicite empréstimos de R$ 8 milhões.
Se o sistema considerar apenas o identificador individual de cada empresa, poderá interpretar as operações como exposições independentes.
Entretanto, o grupo inteiro acumulará R$ 24 milhões de crédito.
Se o limite consolidado for R$ 15 milhões, a exposição ultrapassará o parâmetro permitido.
Um controle baseado apenas no cliente individual falharia.
O sistema precisaria calcular a exposição de todo o grupo econômico.
Isso exige identificar beneficiários finais e relações societárias relevantes.
Também exige controlar mudanças de propriedade e relações indiretas.
Não basta colocar o nome da empresa numa tabela.
É necessário compreender quem efetivamente controla a operação.
Outra situação importante envolve pagamentos circulares.
Uma empresa recebe financiamento.
Transfere recursos a outra.
A segunda utiliza parte do dinheiro para liquidar obrigações da primeira.
Se a análise observar apenas os pagamentos registrados, poderá concluir que os créditos estão sendo honrados.
Mas o dinheiro talvez esteja circulando sem geração econômica independente correspondente.
Isso não prova necessariamente fraude. Existem operações legítimas de tesouraria e financiamento intragrupo.
A investigação deve analisar contratos, origem dos recursos, finalidade econômica e capacidade real de pagamento.
O objetivo da auditoria é identificar substância econômica, não simplesmente desenhar setas entre contas.
📡 Capítulo XI — Por que a nuvem não resolveu o problema?
Computação em nuvem oferece vantagens significativas.
Ela permite escalabilidade, automação, disponibilidade e padronização de infraestrutura.
Entretanto, existe uma diferença entre segurança operacional e governança financeira.
A segurança operacional procura garantir que sistemas estejam disponíveis, dados sejam protegidos e acessos indevidos sejam bloqueados.
A governança financeira busca assegurar que recursos estejam adequadamente administrados, riscos sejam compreendidos e informações contábeis sejam confiáveis.
Imagine um banco que executa suas aplicações em servidores extremamente seguros.
Os discos estão criptografados.
As conexões utilizam protocolos robustos.
Os backups funcionam.
Os servidores são monitorados continuamente.
Nada disso comprova que um empréstimo possui garantia suficiente.
Tampouco confirma que uma empresa não esteja vinculada ao controlador.
O fornecedor de nuvem fornece capacidades tecnológicas.
A instituição continua responsável por seus processos de negócio, controles e obrigações regulatórias, de acordo com a distribuição contratual e legal de responsabilidades.
Uma migração para a nuvem também pode produzir novos desafios.
É necessário controlar identidades, permissões, integrações, configurações, custos, dependências e acessos administrativos.
Ambientes multicloud exigem atenção adicional à centralização de evidências.
Se os registros estão distribuídos em vários provedores, a auditoria precisa conseguir reconstruir uma operação inteira, de ponta a ponta.
Thomas Crown perceberia imediatamente a diferença.
Um museu pode possuir alarmes excelentes em cada sala.
Mas alguém precisa observar o movimento entre todas elas.
⚡ Capítulo XII — A corrida bancária na velocidade de um clique
Antigamente, quando um banco enfrentava uma crise de confiança, clientes formavam filas diante das agências.
Hoje, milhares de pessoas conseguem solicitar transferências simultaneamente.
Uma notícia circula pelas redes sociais.
Clientes procuram informações.
Alguns decidem retirar recursos preventivamente.
Outros interpretam as movimentações como confirmação de problemas.
O processo pode acelerar rapidamente.
Isso introduz um desafio importante de liquidez.
Um banco pode possuir ativos de longo prazo, mas não conseguir convertê-los imediatamente em dinheiro para atender todas as solicitações.
Liquidez e solvência são conceitos diferentes.
Liquidez é a capacidade de cumprir obrigações nos vencimentos.
Solvência está relacionada à capacidade patrimonial de suportar perdas e riscos.
Uma instituição pode enfrentar uma crise de liquidez mesmo quando possui ativos de valor superior aos passivos.
Também pode apresentar problemas patrimoniais graves que não seriam resolvidos apenas com um empréstimo temporário de caixa.
A digitalização acelera a movimentação de recursos, mas não constitui, isoladamente, a causa de uma crise.
Por isso, sistemas de gestão de liquidez precisam simular cenários extremos.
Um exercício adequado pode considerar saídas concentradas, perda de confiança, interrupção de canais, indisponibilidade de contrapartes e dificuldades de obtenção de financiamento.
Os resultados devem alimentar planos de contingência efetivos.
Um painel bonito que mostra apenas os depósitos da última semana não substitui testes de estresse.
🔍 Capítulo XIII — Como descobrir problemas antes que o banco entre em colapso?
Agora Catherine Banning assume o comando da investigação.
Ela não procura apenas uma operação suspeita.
Procura padrões.
O primeiro sinal seria o crescimento de crédito muito superior ao crescimento de capital.
O segundo seria a concentração de operações em determinados grupos econômicos.
O terceiro envolveria garantias insuficientes ou cuja existência não pudesse ser comprovada.
O quarto seria uma dependência excessiva de receitas extraordinárias.
O quinto apareceria quando ativos intangíveis ou outros ativos de difícil conversão em caixa representassem uma parcela importante do patrimônio.
Nenhum desses indicadores comprova automaticamente fraude.
Eles representam sinais que justificam análise aprofundada.
Imagine, por exemplo, que um banco apresente crescimento de 50% na carteira de crédito em um ano, enquanto seus recursos próprios cresçam apenas 5%.
Esse resultado pode ter explicações legítimas, dependendo da composição dos ativos, do risco assumido e dos requisitos regulatórios.
Entretanto, seria necessário verificar se a expansão continua compatível com os limites prudenciais.
Outro exemplo seria um aumento muito expressivo nos ativos intangíveis.
A auditoria deveria solicitar contratos, comprovantes de pagamento, evidências de entrega, critérios de capitalização, testes de recuperabilidade e cronogramas de amortização.
Também deveria identificar fornecedores relacionados ao controlador.
O objetivo não é considerar software um ativo suspeito por natureza.
É comprovar que o valor registrado possui fundamento.
A melhor auditoria não espera que o balanço apresente um desastre. Ela investiga os sinais que aparecem antes dele.
🤖 Capítulo XIV — A inteligência artificial poderia ter identificado os riscos?
A inteligência artificial pode auxiliar bastante.
Imagine um sistema que analisa diariamente milhares de operações de crédito.
O modelo identifica padrões incomuns, concentrações, relacionamentos societários e comportamentos financeiros que merecem investigação.
Também pode comparar movimentações com histórico de clientes e indicadores de risco.
Entretanto, é importante evitar uma ilusão perigosa.
IA não transforma automaticamente dados incompletos em conhecimento verdadeiro.
Se as informações sobre beneficiários finais estiverem erradas, o modelo poderá deixar de identificar relações relevantes.
Se seus dados de treinamento contiverem operações fraudulentas tratadas como normais, ele poderá aprender padrões inadequados.
E um modelo generativo pode apresentar explicações convincentes sem evidência suficiente.
Por isso, uma arquitetura responsável deve separar três funções.
A primeira é a detecção de anomalias.
A segunda é a aplicação de regras determinísticas.
A terceira é a investigação humana.
Um sistema de IA pode recomendar uma revisão.
Uma regra COBOL pode bloquear uma operação que exceda um limite objetivo.
Um analista autorizado deve examinar a documentação e tomar a decisão de negócio apropriada.
Também são indispensáveis explicabilidade, validação dos modelos, monitoramento de falsos positivos e controle de alterações.
A IA deve ampliar a capacidade da auditoria.
Nunca servir como justificativa para eliminar a responsabilidade humana.
🧪 Capítulo XV — Um laboratório completo de prevenção para iniciantes
Vamos transformar nossa investigação em um pequeno projeto de aprendizagem.
O nome será Projeto Crown Shield.
A missão é desenvolver controles básicos para uma carteira bancária fictícia.
Etapa 1 — Organizar os dados
Crie um arquivo contendo identificador do cliente, contrato, valor do crédito, grupo econômico e situação documental.
Utilize apenas dados fictícios.
Nunca copie dados bancários reais para ambientes de estudo.
Etapa 2 — Validar os registros
Desenvolva um programa COBOL que rejeite identificadores vazios, valores inválidos e documentos obrigatórios ausentes.
Em aplicações reais, validações devem incluir formatos, domínios, consistência entre campos e regras de negócio.
Etapa 3 — Calcular limites individuais
Some os contratos de cada cliente.
Compare o resultado com seus limites aprovados.
Lembre-se de considerar contratos já existentes e operações simultâneas.
Etapa 4 — Consolidar os grupos econômicos
Utilize uma tabela de relacionamentos para identificar empresas pertencentes ao mesmo grupo.
Calcule a exposição consolidada.
Não permita que o controle seja contornado apenas dividindo operações entre diferentes empresas.
Etapa 5 — Verificar garantias
Registre tipo, valor, validade e documentação da garantia.
Não considere automaticamente como disponível uma garantia inexistente, vencida ou já comprometida com outra obrigação.
Etapa 6 — Registrar as decisões
Cada operação deverá possuir identificador único, horário, usuário responsável, regra aplicada e resultado.
Alterações precisam preservar histórico.
O objetivo é permitir reconstruir posteriormente o caminho de cada decisão.
Etapa 7 — Implementar aprovação independente
Operações que excedam determinados parâmetros deverão exigir autorização adicional.
O responsável pela aprovação não deverá possuir liberdade irrestrita para alterar os dados que justificam sua própria decisão.
Etapa 8 — Criar relatórios periódicos
Utilize COBOL, SQL e ferramentas de processamento em lote para gerar relatórios de exceções.
Num ambiente IBM Z, JCL pode orquestrar etapas de execução e DFSORT pode auxiliar na organização e consolidação dos arquivos.
Etapa 9 — Simular incidentes
Introduza deliberadamente dados fictícios problemáticos.
Experimente contratos duplicados.
Empresas relacionadas.
Garantias vencidas.
Operações acima do limite.
Documentos ausentes.
Verifique se os controles identificam os cenários esperados.
Etapa 10 — Realizar uma auditoria independente
Peça que outra pessoa revise os resultados.
Essa etapa talvez seja a mais importante de todas.
Um desenvolvedor pode conhecer muito bem seu próprio programa e, justamente por isso, deixar de questionar determinadas hipóteses.
Uma revisão independente ajuda a identificar aquilo que a equipe original não percebeu.
🕵️ Capítulo XVI — As dez lições que Thomas Crown deixaria para o mundo bancário
Primeira lição: tecnologia moderna não substitui governança.
Um aplicativo sofisticado pode conviver com decisões financeiras inadequadas.
Segunda lição: a existência do registro não comprova a existência do ativo.
É necessário verificar contratos, contrapartes e evidências independentes.
Terceira lição: identifique quem realmente controla as empresas.
Operações distribuídas entre várias pessoas jurídicas podem representar riscos concentrados.
Quarta lição: controle quem pode criar, aprovar e modificar transações.
A segregação de funções é indispensável.
Quinta lição: não confunda crescimento comercial com solidez financeira.
Milhões de clientes não garantem patrimônio suficiente.
Sexta lição: teste liquidez e solvência separadamente.
Um banco precisa administrar suas obrigações de curto prazo e sua capacidade de suportar perdas.
Sétima lição: investigue ativos intangíveis relevantes.
Software pode representar investimento legítimo, mas seus valores precisam de documentação e critérios contábeis adequados.
Oitava lição: preserve evidências independentes.
Logs, documentos e relatórios devem permitir reconstruir operações mesmo depois de mudanças nos sistemas.
Nona lição: automatize a detecção sem automatizar cegamente a confiança.
Alertas eletrônicos são úteis, mas exigem interpretação e encaminhamento.
Décima lição: proteja também a independência dos auditores.
Nenhum sistema técnico consegue compensar integralmente uma estrutura institucional em que alertas sejam sistematicamente ignorados.
🎩 Capítulo XVII — Easter egg: o homem do chapéu-coco e os mil clones
Quem assistiu ao filme de 1999 provavelmente recorda uma das sequências mais marcantes.
Thomas Crown utiliza uma multidão de homens com roupas semelhantes e chapéus-coco, numa referência visual à obra de René Magritte.
A cena transforma a identificação do verdadeiro personagem num desafio.
Agora imagine uma investigação bancária.
O auditor encontra dezenas de empresas com nomes diferentes.
Cada uma possui cadastro próprio.
Cada uma apresenta contratos formalmente separados.
Cada uma movimenta recursos por caminhos diferentes.
O sistema enxerga dezenas de entidades.
Mas será que existe um mesmo grupo econômico por trás delas?
Essa é a versão financeira dos homens de chapéu-coco.
O easter egg é também uma lição de modelagem de dados.
Identificadores diferentes não significam necessariamente riscos independentes.
Por isso, sistemas modernos precisam considerar relações societárias, beneficiários finais, vínculos econômicos e informações atualizadas.
No mundo de Crown, o objetivo era confundir a identificação visual.
No mundo bancário, uma estrutura societária complexa pode dificultar a identificação do risco consolidado, mesmo quando não exista intenção fraudulenta.
Catherine Banning não se contentaria em contar os chapéus.
Ela investigaria quem está por baixo deles.
⚖️ Capítulo XVIII — O que governos, reguladores e bancos precisam fazer?
Os casos Ueno e Master demonstram a importância de combinar supervisão prudencial, controles internos e transparência.
O primeiro requisito é melhorar a qualidade dos dados regulatórios.
As autoridades precisam receber informações que permitam analisar concentração, exposição, qualidade de crédito, solvência e liquidez.
O segundo é verificar a consistência das informações recebidas.
Relatórios produzidos automaticamente não são necessariamente independentes dos sistemas que originaram os números.
O terceiro requisito envolve inspeções orientadas por risco.
Instituições que apresentam expansão acelerada, operações complexas ou exposição concentrada podem exigir atenção proporcionalmente maior.
O quarto é exigir comprovação adequada para operações relevantes.
Carteiras de crédito, garantias e ativos intangíveis precisam possuir documentação verificável.
O quinto é estabelecer mecanismos efetivos de responsabilização.
Quando são identificadas deficiências, devem existir processos claros para correção, acompanhamento e eventual sanção, respeitando os procedimentos legais aplicáveis.
O sexto envolve a proteção dos depositantes.
Regimes de garantia de depósitos precisam de comunicação clara, regras conhecidas e capacidade operacional para executar pagamentos quando necessário.
Finalmente, a sociedade deve receber informações suficientes para compreender os riscos sem depender exclusivamente de rumores.
Transparência não significa divulgar dados bancários protegidos.
Significa apresentar informações públicas confiáveis, tempestivas e compreensíveis.
☕ Epílogo — Catherine encontra o quadro verdadeiro
Voltamos ao museu.
Thomas Crown observa a pintura.
Catherine Banning examina os detalhes.
Ela sabe que a moldura pode ser perfeita.
A iluminação pode ser impecável.
O sistema de segurança pode funcionar sem falhas.
Nada disso responde à pergunta principal.
A pintura é verdadeira?
No universo financeiro, a questão é ainda mais importante.
Um registro bancário representa dinheiro de alguém.
Pode representar a poupança de uma família.
O capital de giro de uma pequena empresa.
O salário de um trabalhador.
Ou recursos reservados à aposentadoria de milhares de pessoas.
Os computadores precisam funcionar corretamente.
Os programas COBOL devem preservar a integridade das transações.
Os sistemas de autorização devem controlar os acessos.
Os bancos de dados precisam manter informações consistentes.
A inteligência artificial pode identificar riscos.
A nuvem pode oferecer escalabilidade.
Mas nenhuma dessas tecnologias dispensa uma pergunta simples:
Aquilo que está registrado corresponde à realidade econômica?
Os casos Ueno Bank e Banco Master mostram por que essa pergunta deve acompanhar cada auditoria, cada sistema e cada decisão financeira.
Não existe plataforma capaz de substituir integralmente responsabilidade, transparência e supervisão independente.
Talvez Thomas Crown encerrasse nossa investigação com um sorriso discreto, ajeitando o chapéu e observando os computadores do banco.
No entanto, Catherine Banning teria a última palavra.
Porque a melhor maneira de impedir um golpe sofisticado não é apenas construir uma fechadura mais resistente.
É compreender o que está sendo protegido, quem controla as chaves e como verificar aquilo que parece verdadeiro.
E essa, meus amigos, é uma das maiores lições que um programador COBOL pode aprender sobre segurança bancária.
📚 Fontes e referências para aprofundamento
Banco Central do Paraguai — Início do procedimento de resolução do Ueno Bank, 3 de novembro de 2026
Banco Central do Brasil — Liquidação extrajudicial do Banco Master, 18 de novembro de 2025
Agência Brasil — Investigação das carteiras de crédito do Master e operações com o BRB
ABC Color — Investigação dos ativos intangíveis de software do Ueno
ABC Color — Antecipações a fornecedores de software e operações com empresas vinculadas
KAL — Soluções de software para os terminais de autoatendimento Ueno
Nota: Os exemplos COBOL, Crown Digital, Crown Shield e as operações financeiras hipotéticas são exclusivamente didáticos. As informações sobre investigações refletem os dados públicos disponíveis até 6 de novembro de 2026 e não constituem determinação de culpa de pessoas ou fornecedores mencionados.
Bellacosa Mainframe
Onde a arqueologia da computação encontra os mistérios da tecnologia moderna.
☕ Até o próximo café — e nunca se esqueça: um RETURN-CODE = 0 não significa que o balanço esteja correto!
