 |
| Bellacosa Mainframe e o risk scoring humano |
☕ Um Café no Bellacosa Mainframe
🕶️ DIABOLIK NO MAINFRAME — Risk Scoring Humano
Quando o sistema deixa de perguntar “o que você fez?” e começa a perguntar “por que você deixou de se comportar como você mesmo?”
Há uma coisa que Diabolik entende melhor do que muitos sistemas antifraude.
A melhor maneira de atravessar uma porta protegida não é necessariamente arrombá-la.
É fazer com que a porta acredite que você deveria estar entrando por ela.
Máscara correta.
Documento correto.
Horário plausível.
Comportamento esperado.
Uma história suficientemente coerente.
Separadamente, cada detalhe parece normal.
E justamente aí começa nossa história.
Porque, em algum lugar dentro de uma enorme instituição financeira, existe um IBM Mainframe processando milhões de eventos e tentando responder a uma pergunta aparentemente simples:
este comportamento faz sentido para esta pessoa?
Bem-vindo ao Risk Scoring Humano.
E nosso guia será Diabolik.
🕶️ CAPÍTULO 1 — Diabolik não quer parecer Diabolik
Imagine um sistema antifraude bastante primitivo.
Sua lógica poderia ser parecida com:
IF TRANSACTION-AMOUNT > 10000
MOVE 'HIGH-RISK' TO RISK-LEVEL
END-IF.
Funciona?
Às vezes.
Mas qualquer pessoa que conheça a regra aprende rapidamente que R$ 10.001 chama atenção e R$ 9.999 talvez não.
Esse é o problema das regras determinísticas isoladas.
Diabolik olha para isso e sorri.
Ele não precisa destruir a regra.
Precisa apenas parecer normal para ela.
Um sistema moderno precisa fazer outra pergunta:
R$ 9.999 é normal para quem está fazendo essa operação?
Para uma grande empresa, talvez seja banal.
Para uma conta que recebe R$ 1.800 por mês e nunca movimentou mais de R$ 3.000, pode ser extraordinário.
Portanto:
RISCO ≠ apenas EVENTO
Uma aproximação muito melhor seria:
RISCO =
EVENTO
+ PESSOA
+ HISTÓRICO
+ CONTEXTO
+ RELACIONAMENTOS
+ TEMPO
É aqui que nasce o Risk Scoring Humano.
🎭 CAPÍTULO 2 — A melhor máscara é uma identidade verdadeira
Sistemas antigos frequentemente tentavam responder:
“Essa pessoa é criminosa?”
Sistemas modernos precisam responder algo mais sutil:
“Esse comportamento combina com essa identidade?”
Essa diferença é gigantesca.
João pode ser um cliente perfeitamente legítimo há quinze anos.
Recebe salário.
Paga supermercado.
Abastece o carro.
Paga escola.
Compra medicamentos.
Viaja uma vez por ano.
Seu comportamento produz uma espécie de impressão digital financeira.
Não precisamos conhecer João pessoalmente para perceber padrões.
JOÃO
│
├── salário mensal
├── supermercado
├── combustível
├── contas domésticas
├── escola
├── financiamento
└── viagens ocasionais
Nenhuma dessas informações isoladamente define João.
Mas juntas produzem seu baseline comportamental.
Agora imagine que alguma coisa muda.
Em uma semana:
JOÃO
│
├── recebe 8 transferências incomuns
├── acessa de novo dispositivo
├── muda telefone
├── realiza operação internacional
├── adiciona beneficiário
└── transfere praticamente todo o saldo
Talvez cada evento seja legítimo.
O problema é a combinação.
Diabolik conseguiu uma identidade verdadeira.
Mas ainda precisa aprender a ser João.
📸 CAPÍTULO 3 — O velho sistema guardava fotografias
Durante décadas, instituições trabalharam muito bem com fotografias cadastrais.
NOME
CPF
ENDEREÇO
RENDA
PROFISSÃO
IDADE
TELEFONE
É uma fotografia.
Ela responde:
Quem é Vagner?
Mas Risk Scoring moderno quer assistir ao filme.
08:03 login
08:04 consulta saldo
08:06 novo favorecido
08:07 alteração cadastral
08:11 transferência
08:13 segunda transferência
08:17 tentativa internacional
Agora temos comportamento.
E comportamento possui uma propriedade fascinante:
ele possui sequência.
Isso significa que:
A + B + C
pode ter significado completamente diferente de:
C + A + B
Exemplo:
troca telefone
→ cadastra dispositivo
→ transfere dinheiro
é diferente de:
transfere dinheiro
→ meses depois troca telefone
Os eventos são semelhantes.
A narrativa é diferente.
🎬 CAPÍTULO 4 — Risk Scoring transforma fotografia em filme
Vamos imaginar um cliente chamado Marco.
Durante 36 meses:
salário → conta
conta → despesas
conta → cartão
conta → investimento
Tudo relativamente previsível.
Então:
DIA 1
novo dispositivo
DIA 2
novo telefone
DIA 3
novo favorecido
DIA 3 + 4 minutos
transferência
DIA 3 + 7 minutos
segunda transferência
Um sistema baseado exclusivamente em valores pode não encontrar nada.
O Risk Engine comportamental observa:
DEVICE_RISK +15
PROFILE_CHANGE +10
NEW_BENEFICIARY +20
VALUE_DEVIATION +25
VELOCITY +20
--------------------------------
RISK SCORE 90
Mas atenção.
Isso é apenas um exemplo didático.
Na vida real, scores podem ser produzidos por regras, modelos estatísticos, machine learning, modelos híbridos e sistemas especializados.
O conceito importante é:
sinais pequenos acumulam contexto.
🧮 CAPÍTULO 5 — O Risk Score entra em cena
Vamos criar nosso fictício:
BELLACOSA HUMAN RISK ENGINE — BHRE
Ele recebe eventos:
LOGIN
TRANSACTION
PROFILE_CHANGE
DEVICE_CHANGE
PASSWORD_RESET
BENEFICIARY_ADD
CARD_PURCHASE
PIX
TED
TRANSFER
ATM
Cada evento entra no motor.
No Mainframe poderíamos imaginar componentes como:
CICS
↓
COBOL
↓
Db2 / VSAM
↓
Risk Engine
↓
Decision
Para transações financeiras modernas, também poderíamos integrar APIs, mensageria e plataformas analíticas externas.
O mainframe não precisa fazer sozinho toda a ciência de dados.
Ele pode ser justamente o coração transacional que pergunta:
“Posso autorizar?”
E recebe:
APPROVE
REVIEW
CHALLENGE
DECLINE
💳 CAPÍTULO 6 — 200 OK não significa “é confiável”
Imagine:
CLIENTE
↓
APP
↓
API
↓
BANK
↓
MAINFRAME
A autenticação está correta.
Token correto.
Senha correta.
Dispositivo reconhecido.
Isso demonstra que determinadas credenciais foram aceitas.
Não demonstra necessariamente que a intenção seja legítima.
Essa distinção é fundamental:
AUTHENTICATION
≠
AUTHORIZATION
≠
TRUST
Diabolik adora quando confundimos essas três coisas.
Ele não precisa falsificar necessariamente tudo.
Talvez tenha acesso legítimo a uma credencial comprometida.
O sistema precisa analisar contexto.
🧠 CAPÍTULO 7 — Risk Scoring não deveria perguntar apenas “quem é você?”
Perguntas melhores:
Quem é você?
De onde costuma acessar?
Quando costuma acessar?
Quanto costuma movimentar?
Para quem costuma transferir?
Quais dispositivos utiliza?
Qual é sua velocidade normal de operações?
Que relacionamento possui com o destinatário?
Esse comportamento já aconteceu anteriormente?
Isso produz uma identidade dinâmica.
Chamaremos de:
Behavioral Identity.
Não é simplesmente CPF.
É uma combinação histórica de comportamentos.
🕸️ CAPÍTULO 8 — E então descobrimos o grafo
Diabolik consegue imitar Marco.
Excelente.
Mas existe um problema.
Ele precisa mandar o dinheiro para algum lugar.
Surge Maria.
MARCO → MARIA
Nada necessariamente estranho.
Mas Maria recebe também de:
JOÃO ──┐
PEDRO ─┤
ANA ───┼──→ MARIA
LUÍS ──┤
MARCO ─┘
Interessante.
Maria envia para Empresa X.
MARIA → EMPRESA X
Empresa X está relacionada a outras entidades.
Agora nossa análise deixa de olhar somente para transações.
Estamos construindo um:
GRAPH.
🕷️ CAPÍTULO 9 — O grafo destrói algumas máscaras
Uma pessoa pode alterar:
nome utilizado,
telefone,
conta,
empresa,
dispositivo,
endereço.
Mas relacionamentos podem revelar padrões.
Imagine:
PESSOA A
│
├── telefone → PESSOA B
│
├── endereço → EMPRESA C
│
├── dispositivo → CONTA D
│
└── transferência → PESSOA E
Cada aresta adiciona contexto.
Agora descobrimos:
PESSOA E
↓
EMPRESA F
↓
CONTA G
↓
PESSOA B
Fechamos um ciclo.
É por isso que Graph Analytics é tão poderoso em fraude e AML.
Ele não pergunta apenas:
Quem recebeu dinheiro?
Pergunta:
Como essas entidades estão relacionadas?
🧩 CAPÍTULO 10 — Risk Scoring humano não significa julgar pessoas
Aqui existe uma distinção ética essencial.
Um sistema não deveria concluir:
“Essa pessoa é criminosa.”
Risk Scoring deve trabalhar com algo muito mais limitado:
“Esta operação apresenta características que justificam controles adicionais.”
Essa diferença protege clientes e instituição.
Score não deveria ser sentença.
Deveria ser sinal.
Por isso podemos ter:
LOW RISK
↓
PROCESS
MEDIUM RISK
↓
ADDITIONAL AUTHENTICATION
HIGH RISK
↓
MANUAL REVIEW
CRITICAL
↓
BLOCK / INVESTIGATION
Dependendo da política, legislação e natureza da operação.
🔎 CAPÍTULO 11 — O caso Gritzbach mostra outro tipo de Risk Scoring
Aqui podemos utilizar o caso apenas como analogia analítica, sem transformar acusações ainda controvertidas em fatos.
Segundo a reconstrução jornalística, Antônio Vinícius Lopes Gritzbach teria atravessado simultaneamente diferentes redes de relacionamento envolvendo integrantes do PCC, negócios, dinheiro, criptomoedas, autoridades e policiais. Ele posteriormente tornou-se colaborador do Ministério Público.
A questão interessante para nosso estudo não é tentar reproduzir qualquer “score do PCC”.
É observar algo universal:
pessoas também existem dentro de grafos de confiança.
Imagine abstratamente:
PESSOA
│
├── dinheiro
├── parceiros
├── clientes
├── fornecedores
├── instituições
├── autoridades
└── informações
Quando uma relação muda, outras podem ser afetadas.
⚖️ CAPÍTULO 12 — Trust Score é contextual
Essa é uma descoberta importantíssima.
Uma pessoa não possui universalmente:
TRUST = 72
Ela pode ser simultaneamente:
Banco A → LOW RISK
Banco B → UNKNOWN
Empresa C → TRUSTED
Sistema D → HIGH RISK
Porque risco depende de contexto.
O mesmo vale para comportamento.
Comprar R$ 8.000 em um restaurante pode ser extraordinário para mim.
Para uma empresa realizando jantar corporativo para 80 pessoas, talvez seja normal.
Portanto:
RISK = EVENT / CONTEXT
e não simplesmente:
RISK = EVENT
🧠 CAPÍTULO 13 — O programador COBOL precisa entender isso
Aqui chegamos ao ponto que frequentemente falta nas formações Mainframe.
O iniciante recebe:
01 WS-RISK-SCORE PIC 9(03).
E pensa:
É um campo numérico de três posições.
Não.
Talvez você esteja olhando para a conclusão de centenas de sinais.
Por trás daqueles três bytes conceituais podem existir:
histórico
perfil
device
geolocalização aproximada
velocity
valor
merchant
beneficiário
produto
canal
horário
relacionamentos
alertas anteriores
O programador Mainframe precisa compreender semântica de negócio, não somente PIC clauses.
💻 CAPÍTULO 14 — Vamos programar um pequeno exemplo
Imagine:
01 WS-RISK-SCORE PIC 9(03) VALUE ZERO.
01 WS-NEW-DEVICE PIC X.
01 WS-NEW-BENEFICIARY PIC X.
01 WS-HIGH-AMOUNT PIC X.
01 WS-PROFILE-CHANGE PIC X.
Então:
IF WS-NEW-DEVICE = 'Y'
ADD 15 TO WS-RISK-SCORE
END-IF
IF WS-NEW-BENEFICIARY = 'Y'
ADD 20 TO WS-RISK-SCORE
END-IF
IF WS-HIGH-AMOUNT = 'Y'
ADD 25 TO WS-RISK-SCORE
END-IF
IF WS-PROFILE-CHANGE = 'Y'
ADD 10 TO WS-RISK-SCORE
END-IF.
Depois:
EVALUATE TRUE
WHEN WS-RISK-SCORE >= 70
MOVE 'REVIEW' TO WS-DECISION
WHEN WS-RISK-SCORE >= 40
MOVE 'CHALLENGE' TO WS-DECISION
WHEN OTHER
MOVE 'APPROVE' TO WS-DECISION
END-EVALUATE.
Didaticamente funciona.
Mas Diabolik imediatamente descobriria um problema.
😈 CAPÍTULO 15 — Diabolik aprende nossas regras
Se:
70 = REVIEW
ele tentará permanecer em:
69
Esse fenômeno é fundamental em sistemas antifraude.
Quando atacantes compreendem controles, adaptam comportamento.
Por isso sistemas precisam evoluir.
Podemos combinar:
RULES
+
STATISTICS
+
BEHAVIOR
+
MACHINE LEARNING
+
GRAPH ANALYTICS
+
HUMAN REVIEW
Nenhum componente precisa ser mágico.
O poder está na combinação.
⏱️ CAPÍTULO 16 — Velocity: Diabolik tem pressa
Um conceito maravilhoso para ensinar ao programador COBOL iniciante é velocity.
Imagine:
09:00 R$ 800
09:03 R$ 900
09:05 R$ 700
09:07 R$ 950
09:09 R$ 850
Nenhuma transação ultrapassa R$ 1.000.
Uma regra:
IF AMOUNT > 10000
não detecta nada.
Mas:
5 TRANSFERS
IN 9 MINUTES
é outro sinal.
Risk Scoring precisa compreender também:
quanto aconteceu em quanto tempo.
🕰️ CAPÍTULO 17 — O tempo transforma o grafo
Agora acrescentamos timestamps:
09:00 A → B
09:02 B → C
09:04 C → D
09:07 D → E
Temos um fluxo.
O grafo agora não mostra apenas:
A — B — C — D — E
Mostra movimento.
Chamamos conceitualmente isso de:
Temporal Graph.
Ele pode revelar mudanças que um grafo estático esconderia.
🏦 CAPÍTULO 18 — E onde entra o IBM Mainframe?
No lugar mais interessante possível.
No coração das operações.
Imagine uma arquitetura:
MOBILE
│
INTERNET
│
▼
API LAYER
│
z/OS Connect
│
▼
┌─────────────────────────────────┐
│ IBM Z │
│ │
│ CICS │
│ │ │
│ ▼ │
│ COBOL ───────► Db2 │
│ │ │
│ ▼ │
│ RISK REQUEST │
│ │ │
└─────┼───────────────────────────┘
│
▼
ANALYTICS / GRAPH / ML
│
▼
RISK SCORE
│
▼
IBM Z
│
▼
DECISION
E isso é importante:
modernização não significa necessariamente retirar o COBOL.
Pode significar permitir que COBOL converse com tecnologias especializadas.
⚡ CAPÍTULO 19 — Porque autorização não pode tomar café
Imagine cartão.
Cliente encosta na máquina.
TAP
↓
ACQUIRER
↓
NETWORK
↓
ISSUER
↓
AUTHORIZATION
O cliente está olhando para o terminal.
Não podemos dizer:
“Aguarde vinte minutos enquanto nosso algoritmo termina.”
A decisão precisa ocorrer rapidamente.
É exatamente aí que sistemas transacionais de alta disponibilidade continuam extremamente relevantes.
Risk Scoring precisa entrar no fluxo sem destruir SLA.
🔐 CAPÍTULO 20 — False Positive: quando prendemos o mordomo
Existe outro perigo.
Se o sistema ficar paranoico:
QUALQUER COISA DIFERENTE
↓
BLOCK
teremos milhares de clientes legítimos irritados.
Chamamos isso de:
false positive.
O cliente viajou para Roma.
Compra jantar.
Sistema:
FRAUDE!
Cliente:
Estou com fome!
😄
Risk Scoring precisa equilibrar:
FRAUD LOSS
↕
CUSTOMER FRICTION
Bloquear tudo é fácil.
Autorizar corretamente é difícil.
🎯 CAPÍTULO 21 — Risk Score não é prova
Isso merece ficar gravado no monitor do programador:
RISK SCORE ≠ GUILT
Score 92 não significa:
“92% criminoso.”
Pode significar apenas que um modelo específico identificou uma combinação de sinais considerada de alto risco segundo sua própria calibração.
A interpretação depende do modelo.
Esse cuidado torna-se ainda mais importante quando falamos em Risk Scoring Humano.
Algoritmos podem produzir vieses.
Dados podem estar errados.
Cadastros podem estar desatualizados.
Relacionamentos podem ser coincidências.
Por isso decisões de grande impacto precisam de governança adequada.
🧪 CAPÍTULO 22 — Explainability: por que deu 92?
Imagine o analista recebendo:
RISK SCORE = 92
Ele pergunta:
Por quê?
Sistema:
Porque sim.
Inaceitável.
Precisamos de reason codes.
R01 NEW DEVICE
R07 NEW BENEFICIARY
R13 UNUSUAL AMOUNT
R22 HIGH VELOCITY
R31 GRAPH RELATION
Então:
SCORE 92
REASONS:
HIGH VELOCITY
NEW DEVICE
NEW BENEFICIARY
BEHAVIOR DEVIATION
Agora existe explicabilidade operacional.
E o COBOL pode desempenhar papel importantíssimo na integração desses reason codes ao fluxo transacional.
🗃️ CAPÍTULO 23 — Não jogue fora os dados antigos!
Aqui existe uma vantagem maravilhosa dos ambientes Mainframe.
Histórico.
Décadas de histórico podem existir.
Isso é ouro para análise comportamental — desde que seja utilizado com governança, finalidade legítima, qualidade e respeito às regras de proteção de dados.
Porque comportamento exige comparação:
HOJE
versus
ONTEM
versus
30 DIAS
versus
1 ANO
Um sistema que conhece apenas hoje não conhece comportamento.
Conhece eventos.
🕵️ CAPÍTULO 24 — Diabolik finalmente comete seu erro
Nosso Diabolik conseguiu:
credencial,
identidade,
dispositivo,
horário plausível,
valor plausível.
Ele parece perfeito.
Mas precisa transferir recursos.
O sistema observa:
DIABOLIK-AS-MARCO
↓
CONTA X
↓
CONTA Y
↓
EMPRESA Z
E o Graph Engine percebe:
EMPRESA Z
↑
CONTA Q
↑
CASO ANTERIOR
A transação não era necessariamente anormal.
O relacionamento era.
E finalmente encontramos aquilo que Diabolik não conseguiu falsificar perfeitamente:
o contexto.
🧠 CAPÍTULO 25 — A verdadeira evolução do antifraude
Primeira geração:
TRANSACTION RULES
Segunda:
TRANSACTION + PROFILE
Terceira:
TRANSACTION + PROFILE + BEHAVIOR
Quarta:
TRANSACTION
+
PROFILE
+
BEHAVIOR
+
DEVICE
+
NETWORK
+
GRAPH
+
TIME
E então entramos no território que chamo aqui de:
HUMAN RISK SCORING
Não porque estejamos julgando o ser humano.
Mas porque estamos tentando compreender o comportamento dentro de seu contexto humano e relacional.
🧑💻 CAPÍTULO 26 — O que o COBOLista iniciante deve aprender
Quando encontrar:
IF RISK-SCORE > 80
não continue lendo imediatamente.
Pergunte:
Quem calculou esse score?
Quais eventos participaram?
Qual janela temporal?
O score expira?
É transacional ou cadastral?
Quais reason codes existem?
O que acontece quando o serviço de risco está indisponível?
Essa última pergunta é especialmente Mainframe.
RISK ENGINE DOWN
E agora?
FAIL OPEN?
Autoriza?
FAIL CLOSED?
Recusa?
FALLBACK RULES?
Usa regras locais?
Essa decisão pode valer milhões.
🚨 CAPÍTULO 27 — 03:17
Nosso easter egg Bellacosa aparece.
03:17 da manhã.
O telefone toca.
War Room.
Fraud Decision Service latency: 4.8 seconds
Authorization queue increasing
Timeout rate: 17%
Alguém diz:
“Vamos bypassar o Risk Engine.”
Silêncio.
Porque isso resolveria performance.
Mas poderia abrir a porta.
Outro propõe:
“Vamos bloquear tudo.”
Também resolveria fraude.
E destruiria o negócio.
O verdadeiro engenheiro Mainframe pergunta:
Qual é o fallback aprovado?
Essa frase separa improvisação de engenharia.
☕ CAPÍTULO 28 — A lição de Diabolik
Durante toda a história procurávamos o homem de máscara preta.
Esse era nosso erro.
Diabolik nunca quis que víssemos a máscara.
Queria que víssemos:
CLIENTE NORMAL
Risk Scoring evoluiu justamente porque fraude sofisticada não precisa parecer fraude.
Pode parecer:
uma compra,
uma transferência,
um login,
uma empresa,
uma conta,
um cliente.
Tudo aparentemente legítimo.
Até observarmos:
QUEM
+
O QUÊ
+
QUANDO
+
ONDE
+
COMO
+
COM QUEM
+
QUANTAS VEZES
+
EM QUE SEQUÊNCIA
Então surge uma história.
🕶️ EPÍLOGO — O Mainframe não procura criminosos
Essa talvez seja a mensagem mais importante para o programador iniciante.
O IBM Mainframe não deveria funcionar como juiz.
O Risk Engine também não.
Eles processam sinais.
EVENT
↓
CONTEXT
↓
HISTORY
↓
RELATIONSHIP
↓
RISK
↓
DECISION
↓
EVIDENCE
E boas arquiteturas mantêm algo fundamental:
rastreabilidade.
Precisamos saber:
qual informação entrou,
qual regra executou,
qual modelo respondeu,
qual score retornou,
qual reason code apareceu,
qual decisão foi tomada,
quando aconteceu
e qual versão estava em produção.
Porque um dia alguém perguntará:
“Por que essa transação foi recusada?”
E PORQUE WS-RISK > 80 não será resposta suficiente.
Diabolik talvez consiga enganar uma regra.
Talvez consiga enganar uma câmera.
Talvez consiga uma identidade perfeita.
Talvez consiga inclusive parecer estatisticamente normal durante algum tempo.
Mas quanto mais dimensões independentes um sistema correlaciona — histórico, comportamento, dispositivo, velocidade, relacionamentos e tempo — mais difícil se torna sustentar uma identidade artificial coerente.
Essa é a batalha moderna.
Não é:
COBOL contra inteligência artificial.
É:
COBOL
+
CICS
+
Db2
+
APIs
+
EVENTS
+
RULES
+
ML
+
GRAPH ANALYTICS
+
HUMAN ANALYST
Cada tecnologia fazendo aquilo que sabe fazer melhor.
E no centro de tudo continua existindo aquela pergunta simples que começou nossa investigação:
“Isto é normal?”
Diabolik ajusta a gravata, olha para o terminal e sorri.
O terminal responde:
TRANSACTION........... VALID
IDENTITY.............. VALID
AUTHENTICATION........ VALID
AMOUNT................ NORMAL
BEHAVIOR.............. UNUSUAL
VELOCITY.............. UNUSUAL
GRAPH RELATION........ HIGH RISK
RISK SCORE............ 92
DECISION.............. REVIEW
Pela primeira vez, Diabolik para de sorrir.
O sistema não descobriu necessariamente quem ele é.
Descobriu algo muito mais interessante.
Ele não está se comportando como a pessoa que afirma ser.
☕ Um Café no Bellacosa Mainframe
Onde até Diabolik descobre que enganar um IF é fácil. Difícil é enganar quarenta anos de histórico.
Para ir mais longe
https://eljefemidnightlunch.blogspot.com/2024/10/diabolik-no-mainframe-o-roubo-perfeito.html
