Bellacosa Mainframe e os riscos de fraude

☕ UM CAFÉ NO BELLACOSA MAINFRAME

🕶️ CID KAGENOU ENTRA NO SOC — QUANDO O PROGRAMADOR COBOL DESCOBRIU QUE O CRIME NÃO ESTAVA NA TRANSAÇÃO

Fraude, AML, lavagem de dinheiro, Entity Resolution, Graph Analytics, centralidade, comunidades, Money Mules, Temporal Graphs, Machine Learning, GNN, COBOL, CICS, Db2, IMS, MQ — e o dia em que Cid Kagenou descobriu que a transação mais importante era justamente aquela que parecia perfeitamente normal.

---

🎬 PRÓLOGO — A TRANSAÇÃO QUE NÃO TINHA NADA DE ERRADO

Era uma terça-feira absolutamente normal no CPD.

O CICS processava transações.

O Db2 armazenava dados.

O MQ entregava mensagens.

O JES2 continuava recebendo jobs como se os últimos cinquenta anos fossem apenas uma longa segunda-feira.

E nosso jovem programador COBOL estava olhando para uma transação:

ORIGEM........: CONTA-18472
DESTINO.......: CONTA-77821
VALOR.........: R$ 4.850,00
HORÁRIO........: 14:32:17
CANAL.........: PIX
STATUS........: PROCESSADA

Nada extraordinário.

O cliente possuía renda compatível.

A conta existia havia anos.

Não havia tentativa de acesso suspeita.

Não havia valor absurdamente alto.

Não havia movimentação internacional.

Nenhuma regra havia disparado.

O programa COBOL poderia tranquilamente fazer:

IF WS-TRANSACTION-VALID
    MOVE '00' TO WS-RETURN-CODE
END-IF.

E seguir a vida.

Foi quando alguém apareceu silenciosamente atrás dele.

Casaco preto.

Expressão séria demais para alguém que acabara de entrar em um CPD.

Era Cid Kagenou.

— Você está olhando para a coisa errada.

O programador virou-se.

— Mas a transação está normal.

Cid sorriu.

— Exatamente.

E naquele momento começava nossa viagem de Transaction Monitoring para Network Monitoring.

---

🧮 CAPÍTULO 1 — PRIMEIRO: O QUE É UMA TRANSAÇÃO?

Antes de falarmos sobre grafos, inteligência artificial ou lavagem de dinheiro, precisamos começar do começo.

Para um sistema bancário, uma transação pode ser representada como um conjunto de informações:

origem
destino
valor
data
hora
canal
moeda
localização
status

No COBOL poderíamos imaginar:

01 TRANSACTION-RECORD.
   05 TRX-ID              PIC X(20).
   05 TRX-SOURCE          PIC X(20).
   05 TRX-DESTINATION     PIC X(20).
   05 TRX-AMOUNT          PIC 9(11)V99.
   05 TRX-DATE            PIC 9(08).
   05 TRX-TIME            PIC 9(06).
   05 TRX-CHANNEL         PIC X(10).

Durante décadas, sistemas antifraude trabalharam fundamentalmente analisando registros desse tipo.

A pergunta era:

Existe alguma coisa estranha nesta transação?

Por exemplo:

IF TRX-AMOUNT > 50000
    MOVE 'Y' TO AML-ALERT
END-IF.

Naturalmente, sistemas financeiros modernos são muito mais sofisticados do que esse IF.

Podemos verificar:

• valor;

• horário;

• país;

• dispositivo;

• frequência;

• localização;

• histórico;

• comportamento anterior;

• tipo de estabelecimento;

• perfil do cliente.

Mas conceitualmente continuamos perguntando:

Esta transação parece diferente daquilo que esperamos?

Isso é Transaction Monitoring.

---

🚨 CAPÍTULO 2 — O PROBLEMA DA TRANSAÇÃO ESTRANHA

Imagine um cliente que normalmente movimenta:

R$ 2.000
R$ 3.500
R$ 4.000
R$ 2.800

De repente aparece:

R$ 900.000

Naturalmente alguma coisa chama atenção.

Mas existe um problema.

Quem pratica fraude ou lavagem de dinheiro profissionalmente também conhece regras.

Imagine que alguém queira movimentar R$ 900.000.

Em vez de:

A ───────── R$ 900.000 ─────────> B

poderia tentar distribuir:

        ┌── R$ 9.000 ──> B
        ├── R$ 8.500 ──> C
        ├── R$ 7.800 ──> D
A ──────┼── R$ 9.200 ──> E
        ├── R$ 8.900 ──> F
        └── ...

Agora cada transação individual pode parecer muito menos extraordinária.

Cid observou o monitor.

— Se você sabe que o inimigo procura monstros, não precisa parecer um monstro.

Esse é o problema.

Uma rede suspeita pode ser construída utilizando transações individualmente banais.

---

🕸️ CAPÍTULO 3 — CID DESENHA UM GRAFO NO QUADRO

Cid pegou uma caneta.

Desenhou:

A ─────→ B

— Isso é um grafo.

O COBOLzeiro olhou desconfiado.

— Só isso?

— Só isso.

Um grafo possui fundamentalmente duas coisas:

NODES

e:

EDGES

Ou, em português:

NÓS
ARESTAS

Um nó representa alguma entidade.

Por exemplo:

PESSOA
CONTA
EMPRESA
CARTÃO
TELEFONE
ENDEREÇO
DISPOSITIVO
IP
E-MAIL
WALLET

Uma aresta representa um relacionamento.

Por exemplo:

POSSUI
TRANSFERIU_PARA
MORA_EM
USA
ACESSOU_COM
É_SÓCIO_DE
RECEBEU_DE
COMPARTILHA

Assim:

[CID]
  |
 POSSUI
  |
[CONTA 01]

é um pequeno grafo.

Agora acrescente:

[CID]
  |
 POSSUI
  |
[CONTA 01]
  |
 TRANSFERIU
  |
[CONTA 02]

E já temos uma rede.

---

🧠 CAPÍTULO 4 — O REGISTRO DEIXOU DE SER O PERSONAGEM PRINCIPAL

Aqui acontece uma mudança conceitual importante.

No Transaction Monitoring:

TRANSACTION
     |
     v
RULE ENGINE
     |
     v
ALERT

Com Machine Learning:

TRANSACTION
     |
     v
FEATURES
     |
     v
MODEL
     |
     v
RISK SCORE

Mas continuamos fundamentalmente analisando o evento.

Com Graph Analytics:

              [PESSOA]
               /    \
              /      \
         [CONTA]    [TELEFONE]
            |            |
        [EMPRESA]    [DEVICE]
            \            /
             \          /
                [IP]

Agora o relacionamento também é informação.

Essa frase merece café:

O dado suspeito pode não estar dentro do registro. Pode estar na relação entre registros perfeitamente normais.

---

🧬 CAPÍTULO 5 — ENTITY RESOLUTION: QUEM É QUEM?

Antes de construir uma boa rede existe um problema brutal.

Imagine os registros:

JOÃO CARLOS SILVA
JOAO C SILVA
J. CARLOS SILVA
JOÃO C. DA SILVA
JC SILVA

Quantas pessoas existem?

Cinco?

Duas?

Uma?

Bem-vindo ao mundo de Entity Resolution.

Entity Resolution tenta descobrir quando registros diferentes provavelmente representam a mesma entidade do mundo real.

Podemos encontrar:

REGISTRO A
Nome: João Carlos Silva
Telefone: 99999-1234

REGISTRO B
Nome: J. C. Silva
Telefone: 99999-1234

O telefone comum aumenta a possibilidade de relacionamento.

Agora:

telefone igual
endereço igual
device fingerprint igual
IP recorrente igual
data de nascimento igual

Nossa confiança aumenta.

Mas atenção.

Entity Resolution trabalha frequentemente com probabilidades e evidências, não necessariamente certezas.

Duas pessoas podem morar no mesmo endereço.

Uma família pode compartilhar telefone.

Centenas de pessoas podem aparecer atrás de um mesmo IP corporativo.

Por isso:

MESMO IP

não significa:

MESMA PESSOA

Essa distinção salva investigações ruins.

---

🕵️ CAPÍTULO 6 — CID ENCONTRA AS MONEY MULES

Agora imagine:

              ┌──> B
              ├──> C
ORIGEM ───────┼──> D
              ├──> E
              └──> F

B, C, D, E e F podem funcionar como intermediários.

No universo de fraude financeira encontramos o conceito de money mule.

São contas utilizadas para receber, movimentar ou repassar recursos relacionados a atividades criminosas. Dependendo do caso, o titular pode participar conscientemente, ser recrutado ou até compreender apenas parcialmente aquilo em que está envolvido.

O interessante para nossa análise é estrutural.

Separadamente:

ORIGEM → B

parece uma transação.

ORIGEM → C

outra.

ORIGEM → D

outra.

Mas juntas:

          B
        ↗
       C
      ↗
ORIGEM → D
      ↘
       E
        ↘
          F

formam uma topologia.

Agora não estamos procurando somente transações suspeitas.

Estamos procurando estruturas suspeitas.

---

🌟 CAPÍTULO 7 — CENTRALIDADE: QUEM É IMPORTANTE?

Cid desenhou:

      B
      |
A ─── X ─── C
      |
      D

— Quem parece importante?

— X.

Exatamente.

Graph Analytics possui diferentes medidas de centralidade.

Uma das mais intuitivas é a Degree Centrality.

Ela observa quantas conexões determinado nó possui.

X possui:

A
B
C
D

ligados a ele.

Mas existe outra medida fascinante.

Betweenness Centrality

Imagine:

A──B──C──X──D──E──F

X talvez não tenha centenas de conexões.

Porém retire X:

A──B──C

D──E──F

As duas regiões ficam desconectadas.

X era uma ponte.

Em uma investigação, isso pode levantar perguntas interessantes.

Quem conecta dois grupos?

Quem intermedeia fluxos?

Quem aparece repetidamente no caminho entre comunidades?

Cid sorriu.

— Poder não significa necessariamente ter muitos subordinados. Às vezes significa estar exatamente no caminho pelo qual todos precisam passar.

Shadow Garden aprovou essa definição.

Easter egg desbloqueado.

---

👑 CAPÍTULO 8 — EIGENVECTOR CENTRALITY E PAGERANK

Existe uma pergunta ainda mais sofisticada.

Não basta perguntar:

Quantas conexões você possui?

Podemos perguntar:

Com quem você está conectado?

Imagine duas pessoas.

A possui 100 conexões periféricas.

B possui somente cinco conexões, mas todas com nós extremamente relevantes.

Dependendo do objetivo analítico, B pode ser estruturalmente muito mais interessante.

É a intuição por trás de famílias de métricas como Eigenvector Centrality e, com características próprias, algoritmos como PageRank.

Em linguagem de boteco:

Não importa somente quantas pessoas conhecem você. Importa também quem são essas pessoas.

---

🏘️ CAPÍTULO 9 — COMMUNITY DETECTION

Agora nossa rede cresceu:

 A──B──C
 |\ | /|
 D──E──F

     |
     X
     |

 P──Q──R
 |\ | /|
 S──T──U

Visualmente aparecem dois grupos.

Algoritmos de Community Detection procuram regiões da rede com conexões internas particularmente densas.

Podemos descobrir:

COMMUNITY A
37 contas

COMMUNITY B
82 contas

COMMUNITY C
14 empresas

Isso sozinho não significa fraude.

Uma comunidade pode representar:

• funcionários de uma empresa;

• familiares;

• clientes de uma loja;

• fornecedores;

• estudantes;

• participantes de um marketplace.

Por isso graph analytics não deve transformar:

PADRÃO

automaticamente em:

CRIME

Ele transforma padrões em hipóteses investigativas.

---

🚿 CAPÍTULO 10 — FAN-IN E FAN-OUT

Cid desenhou:

A ─┐
B ─┤
C ─┼──> X
D ─┤
E ─┘

Isso é um padrão de fan-in.

Muitos nós convergem para um.

Pode representar algo perfeitamente legítimo:

clientes → supermercado
moradores → condomínio
compradores → marketplace

Mas dependendo do contexto pode merecer análise.

Agora o inverso:

        ┌──> A
        ├──> B
X ──────┼──> C
        ├──> D
        └──> E

Temos fan-out.

Também pode ser perfeitamente legítimo:

empresa → salários
seguradora → indenizações
marketplace → vendedores

A lição é fundamental:

Topologia sem contexto não é conclusão.

---

🔄 CAPÍTULO 11 — O DINHEIRO QUE VOLTOU PARA CASA

Imagine:

A → B
    ↓
    C
    ↓
    D
    ↓
    A

Temos um ciclo.

Ou:

A → B → C → A

Graph analytics permite procurar estruturas assim.

Mas novamente:

CYCLE = FRAUDE

seria uma regra perigosamente simplista.

Fluxos comerciais legítimos podem produzir circularidade.

A coisa fica mais interessante quando combinamos características:

ciclo
+
contas recentes
+
movimentação rápida
+
dispositivos compartilhados
+
perfil econômico incompatível
+
contrapartes incomuns

Agora temos uma hipótese muito mais rica.

---

⏱️ CAPÍTULO 12 — O TEMPO ENTRA NO GRAFO

Até agora desenhamos grafos estáticos.

Mas dinheiro se movimenta no tempo.

Observe:

10:01 A → B
10:04 B → C
10:07 C → D
10:11 D → E

Compare com:

Janeiro   A → B
Março     B → C
Junho     C → D
Dezembro  D → E

A topologia pode parecer semelhante.

O comportamento temporal é completamente diferente.

Surge então o Temporal Graph.

Não queremos apenas saber:

WHO → WHO

Queremos:

WHO
WHO → WHO
WHEN
HOW MUCH
HOW OFTEN
HOW FAST

Velocidade passa a ser uma feature.

Frequência também.

Recorrência também.

---

📈 CAPÍTULO 13 — A REDE TAMBÉM POSSUI COMPORTAMENTO

Janeiro:

A──B

Fevereiro:

A──B──C

Março:

A──B──C
   |
   D

Abril:

      A
     / \
    B   C
   /|\ /|\
  D E F G H

Talvez nenhum pagamento isoladamente seja absurdo.

Mas alguma coisa aconteceu com A.

Em poucos meses ele passou de nó periférico para hub.

Agora podemos perguntar:

Por que esta entidade mudou tão rapidamente de posição estrutural?

Isso é maravilhoso porque juntamos:

Behavior Analytics
+
Graph Analytics
+
Temporal Analysis

Estamos analisando o comportamento da própria rede.

---

🧠 CAPÍTULO 14 — MACHINE LEARNING ENTRA NA SALA

Um modelo tradicional poderia receber features como:

amount
hour
country
channel
customer_age
account_age
transaction_frequency

E calcular:

RISK = 0.73

Mas agora podemos fornecer características estruturais:

degree
in_degree
out_degree
community
centrality
number_of_neighbors
velocity
cycle_count
shared_devices

E podemos ir ainda além.

Entram as Graph Neural Networks, ou GNNs.

Simplificando brutalmente, modelos desse tipo podem aprender representações considerando características do nó e informações provenientes de sua vizinhança no grafo.

Cid resumiu:

— O modelo antigo pergunta quem você é.

Escreveu:

WHO ARE YOU?

Depois:

WHO ARE YOU?

WHO ARE YOUR NEIGHBORS?

WHO ARE THEIR NEIGHBORS?

HOW ARE YOU CONNECTED?

Isso muda radicalmente o contexto disponível ao modelo.

---

🏦 CAPÍTULO 15 — O INIMIGO CHAMADO SILO

Agora encontramos um problema institucional.

Banco A enxerga:

A → B

Banco B:

B → C

Banco C:

C → D

Banco D:

D → X

Cada instituição talvez enxergue apenas um fragmento.

Mas conceitualmente a estrutura completa seria:

A → B → C → D → X

Isso explica por que investigações financeiras modernas têm interesse crescente em colaboração analítica, dentro dos limites legais aplicáveis.

O problema é óbvio:

não podemos simplesmente fazer:

SELECT *
FROM TODOS_OS_BANCOS_DO_MUNDO;

Embora todo DBA tenha sentido um arrepio nesse momento.

---

🔐 CAPÍTULO 16 — PRIVACIDADE ENTRA NA EQUAÇÃO

Quanto mais poderosa fica a capacidade de conectar informações, maior fica a responsabilidade.

Estamos lidando potencialmente com:

dados pessoais
informações financeiras
endereços
dispositivos
relacionamentos
comportamento

Logo entram questões como:

LGPD
GDPR
sigilo bancário
controle de acesso
auditoria
governança
minimização
retenção
jurisdição

Isso abre espaço para as chamadas Privacy Enhancing Technologies, ou PETs.

Entre tecnologias e abordagens pesquisadas para diferentes problemas encontramos:

Federated Learning
Secure Multi-Party Computation
Private Set Intersection
Homomorphic Encryption

A ideia geral é fascinante:

Como extrair conhecimento conjunto reduzindo a necessidade de reunir todos os dados brutos em um único lugar?

Não existe uma tecnologia mágica que resolva todos os casos.

Cada solução envolve compromissos de desempenho, segurança, complexidade, privacidade e governança.

---

🦖 CAPÍTULO 17 — E O MAINFRAME?

O jovem COBOLzeiro levantou a mão.

— Muito bonito. Mas onde eu entro nessa história?

Cid apontou para o z/OS.

— Onde você acha que muitas dessas transações nasceram?

Touché.

Um ambiente financeiro pode possuir:

COBOL
CICS
Db2
IMS
VSAM
MQ

O mainframe não precisa necessariamente transformar-se no ambiente responsável por toda análise de grafos.

Podemos ter:

            IBM Z
              |
    +---------+---------+
    |         |         |
   CICS      Db2       IMS
    |         |         |
    +---------+---------+
              |
             MQ
              |
              v
       EVENT PIPELINE
              |
              v
      DATA PROCESSING
              |
              v
    ENTITY RESOLUTION
              |
              v
        GRAPH MODEL
              |
              v
      GRAPH ANALYTICS
              |
              v
         ML / GNN
              |
              v
       CASE MANAGEMENT
              |
              v
        INVESTIGADOR

O mainframe continua fazendo aquilo em que é excepcional:

processar transações críticas com consistência, segurança e escala.

Outras camadas enriquecem esses dados.

---

🔧 CAPÍTULO 18 — PASSO A PASSO: DA TRANSAÇÃO AO GRAFO

Vamos transformar teoria em arquitetura.

Passo 1 — Capturar o evento

Nosso sistema produz:

TXID=984731
SOURCE=A
DESTINATION=B
AMOUNT=4850
TIME=14:32

Passo 2 — Enriquecer

Acrescentamos:

customer
account
device
IP
channel
location
merchant

Passo 3 — Resolver entidades

Tentamos descobrir:

ACCOUNT A
ACCOUNT B
DEVICE C
PHONE D

pertencem ou se relacionam com quais entidades reais?

Passo 4 — Criar nós

[PESSOA]
[CONTA]
[DEVICE]
[EMPRESA]

Passo 5 — Criar arestas

PESSOA ──POSSUI──> CONTA

CONTA ──TRANSFERIU──> CONTA

CONTA ──USOU──> DEVICE

Passo 6 — Calcular features

degree
centrality
community
velocity
fan-in
fan-out
cycles

Passo 7 — Procurar anomalias

Comparamos:

entidade
vs.
histórico
vs.
peer group
vs.
comunidade
vs.
rede

Passo 8 — Gerar evidências

Não:

CRIMINOSO!

Mas:

ALERTA 9281

Motivos:
- aumento anormal de conexões;
- alto fan-in;
- repasse rápido;
- dispositivos compartilhados;
- ponte entre duas comunidades.

Passo 9 — Investigação humana

Finalmente:

ANALISTA
   |
   +--> KYC
   +--> histórico
   +--> documentos
   +--> contexto
   +--> evidências autorizadas

Essa separação é fundamental.

---

⚠️ CAPÍTULO 19 — CORRELAÇÃO NÃO É CULPA

Este talvez seja o capítulo mais importante.

Imagine:

A ──DEVICE── B

O mesmo dispositivo foi utilizado.

Isso pode significar:

mesma pessoa

Mas também:

marido e esposa
pai e filho
computador empresarial
terminal compartilhado
assistência técnica

Outro exemplo:

A ──ADDRESS── B

Pode representar:

família
empresa
condomínio
coworking
endereço contábil

Graph analytics produz contexto.

Não sentença.

Um sistema irresponsável poderia transformar proximidade matemática em acusação.

Um sistema bem projetado transforma proximidade em:

HIPÓTESE
+
EVIDÊNCIA
+
INVESTIGAÇÃO

---

🧪 CAPÍTULO 20 — O LABORATÓRIO DO COBOLZEIRO

Quer aprender isso de verdade?

Construa um pequeno laboratório.

Crie:

20 pessoas
30 contas
10 dispositivos
50 transações

Depois invente um padrão:

P01 → P07
P02 → P07
P03 → P07
P04 → P07

P07 → P15

P15 → P18
P15 → P19
P15 → P20

Agora responda:

1. Quem possui maior degree?

2. Quem recebe de mais entidades?

3. Quem distribui para mais entidades?

4. Existe uma ponte?

5. Existem comunidades?

6. Existem ciclos?

7. Qual nó desaparecido fragmentaria mais a rede?

8. Como a resposta muda se acrescentarmos tempo?

Depois acrescente:

DEVICE-001

utilizado por:

P03
P07
P15

Observe como uma única informação muda sua interpretação.

Esse exercício ensina mais sobre graph analytics do que decorar vinte definições.

---

🎮 CAPÍTULO 21 — CID KAGENOU ENCONTRA O VERDADEIRO ADVERSÁRIO

O COBOLzeiro voltou à primeira transação:

JOÃO → MARIA
R$ 4.850

Continuava normal.

Mas agora ele perguntou:

Quem é Maria?

Depois:

Quem mais transfere para Maria?

Depois:

Para quem Maria transfere?

Depois:

Que dispositivos essas contas compartilham?

Depois:

Existem comunidades?

Depois:

Quem conecta essas comunidades?

Depois:

Como essa rede mudou nos últimos seis meses?

Cid finalmente sorriu.

O programador havia compreendido.

A pergunta nunca deveria ter sido apenas:

Esta transação é estranha?

Existia uma pergunta maior:

Esta transação faz parte de uma estrutura estranha?

---

🧭 CAPÍTULO 22 — QUATRO GERAÇÕES DE DETECÇÃO

Podemos organizar nossa viagem assim:

FRAUDE 1.0
|
+-- EVENTO
    "Essa transação é estranha?"

Depois:

FRAUDE 2.0
|
+-- COMPORTAMENTO
    "Esse comportamento é estranho?"

Depois:

FRAUDE 3.0
|
+-- REDE
    "Essa rede é estranha?"

E finalmente:

FRAUDE 4.0
|
+-- EVOLUÇÃO DA REDE
    "Essa rede está mudando de maneira estranha?"

Não significa que uma geração elimina a anterior.

Muito pelo contrário.

O sistema mais interessante combina:

TRANSACTION MONITORING
        +
BEHAVIOR ANALYTICS
        +
ENTITY RESOLUTION
        +
GRAPH ANALYTICS
        +
TEMPORAL ANALYSIS
        +
MACHINE LEARNING
        +
HUMAN INVESTIGATION

Cada camada vê algo que as outras talvez não vejam.

---

🕶️ EPÍLOGO — A EMINÊNCIA NAS SOMBRAS DO GRAFO

No fim do expediente, o COBOLzeiro finalmente percebeu algo curioso.

Durante toda a investigação, Cid não havia encontrado nenhuma transação espetacular.

Nenhum milhão transferido às três da manhã.

Nenhum hacker de capuz.

Nenhum ACCESS DENIED piscando em vermelho.

Nenhum:

IF CRIMINAL = TRUE

Apenas pequenas conexões.

Um telefone aqui.

Um dispositivo ali.

Uma conta recebendo dinheiro.

Outra repassando.

Um endereço compartilhado.

Uma ponte entre dois clusters.

Uma sequência rápida demais.

Uma comunidade surgindo silenciosamente.

E então o desenho apareceu.

Era essa a lição.

Em sistemas complexos, o evento mais importante nem sempre é aquele que chama atenção.

Às vezes ele é:

normal
normal
normal
normal
normal
normal

até alguém perguntar:

COMO ESSES NORMAIS
ESTÃO CONECTADOS?

O velho programador de mainframe talvez reconheça essa sensação.

Você abre o SDSF.

Olha os jobs.

Nenhum abend extraordinário.

Nada explodiu.

Mas alguma coisa não parece certa.

Não é necessariamente uma linha.

É o padrão.

Graph analytics leva essa intuição para outro domínio.

A transação é apenas o registro.

O relacionamento cria contexto.

A rede revela estrutura.

O tempo revela comportamento.

E a investigação transforma padrões em perguntas.

Cid colocou as mãos nos bolsos e caminhou em direção à saída.

Antes de desaparecer pela porta do CPD, deixou apenas uma última frase:

Se todos estão procurando a transação suspeita, talvez o melhor lugar para esconder alguma coisa seja dentro de mil transações perfeitamente normais.

O COBOLzeiro olhou novamente para o monitor.

TX-000001   NORMAL
TX-000002   NORMAL
TX-000003   NORMAL
TX-000004   NORMAL
TX-000005   NORMAL

Abriu outra tela.

Agora havia um grafo.

             [A]
            /   \
          [B]   [C]
           \     /
            [X]
           / | \
         [D][E][F]
             |
            [G]

Ele tomou um gole de café.

E percebeu que, pela primeira vez naquele dia, estava olhando para os dados certos.

*** SHADOW GARDEN JOB COMPLETED ***
MAXCC=0000

☕ Bem-vindo ao Bellacosa Mainframe.

Onde até uma transação inocente pode ter uma história muito maior quando você descobre quem está nas sombras do grafo.