Bellacosa Mainframe e o Risk Score

☕ Um Café no Bellacosa Mainframe

🕶️ DIABOLIK NO MAINFRAME — O Roubo Perfeito e o Risk Score que Percebeu Tudo

Fraude, AML, comportamento, dispositivos, transações, grafos e Risk Scoring em tempo real — porque o criminoso perfeito não precisa cometer um erro. Basta fazer algo que não combine com a vítima.

Há uma diferença fundamental entre um ladrão comum e Diabolik.

O ladrão comum tenta abrir a porta.

Diabolik já sabe onde está a chave.

O ladrão comum aparece diante da câmera.

Diabolik estudou o ângulo morto.

O ladrão comum rouba o cartão.

Diabolik prefere que o banco continue acreditando que o verdadeiro dono está usando o cartão.

E é justamente por isso que ele é um excelente personagem para entendermos o Risk Scoring moderno.

Imagine uma noite qualquer.

03:17.

Em algum lugar da cidade, um cliente chamado João dorme tranquilamente.

Seu cadastro no banco diz:

CUSTOMER: JOAO
KYC: OK
PEP: NO
SANCTIONS: NO
ACCOUNT AGE: 8 YEARS
RISK: LOW

Tudo parece normal.

O problema é que João não está usando sua conta.

Diabolik está.

E nosso sistema tem poucos milissegundos para perceber isso.

Bem-vindo ao estranho mundo onde conhecer a identidade do cliente já não basta.

---

🕶️ CAPÍTULO 1 — Diabolik não quer parecer Diabolik

O Risk Scoring tradicional tinha uma visão relativamente confortável do mundo.

O cliente chegava, apresentava seus documentos, passava pelas verificações necessárias e recebia determinada classificação:

LOW
MEDIUM
HIGH

Era quase uma fotografia.

No momento em que João abriu sua conta, o banco verificou identidade, endereço, documentos, profissão, renda e outros elementos necessários ao processo.

Depois disso:

JOAO = LOW RISK

O problema está na palavra é.

João não é necessariamente LOW RISK.

João estava associado a determinado nível de risco naquele contexto e naquele momento.

Meses depois, muita coisa pode ter mudado.

O cliente pode trocar de telefone, viajar, mudar endereço, começar a movimentar valores diferentes, adicionar beneficiários, alterar senhas e utilizar novos dispositivos.

E existe ainda uma possibilidade mais inquietante:

João continua sendo João.

Mas alguém conseguiu assumir sua identidade digital.

Diabolik não precisa modificar o cadastro.

Pelo contrário.

Quanto menos alterar, melhor.

---

🎭 CAPÍTULO 2 — A melhor máscara é uma identidade verdadeira

Essa é uma das ideias mais interessantes da fraude digital.

Imagine que um criminoso tenha:

CPF correto
nome correto
endereço correto
data de nascimento correta
credenciais corretas

Uma verificação baseada exclusivamente em identidade pode encontrar:

IDENTITY = VALID

E isso pode ser perfeitamente verdadeiro.

A identidade realmente existe.

O problema é outro:

quem está controlando aquela identidade naquele instante?

É uma diferença monumental.

Podemos ter:

IDENTITY RISK = LOW

e simultaneamente:

BEHAVIOR RISK = HIGH
DEVICE RISK   = HIGH
SESSION RISK  = HIGH

Por isso o Risk Scoring moderno deixa de perguntar apenas:

Quem é você?

E começa a perguntar:

O que está acontecendo?

---

📸 CAPÍTULO 3 — O velho sistema guardava fotografias

Vamos imaginar um sistema fictício chamado BELLABANK.

No cadastro de João encontramos:

CUSTOMER-ID : 00091827364
NAME        : JOAO SILVA
KYC-STATUS  : APPROVED
PEP-FLAG    : N
AML-RISK    : LOW
COUNTRY     : BR

Excelente.

Só que o cadastro não consegue contar sozinho a história seguinte:

03:17 NEW DEVICE

03:19 PASSWORD RESET

03:21 NEW BENEFICIARY

03:22 TRANSFER R$ 9.800

Cada evento isoladamente pode ser legítimo.

Pessoas compram celulares.

Pessoas esquecem senhas.

Pessoas cadastram beneficiários.

Pessoas transferem R$9.800.

Mas a sequência inteira é muito mais interessante.

É aí que começamos a sair da fotografia e entrar no filme.

---

Bellacosa Mainframe e o risk scoring

🎬 CAPÍTULO 4 — Risk Scoring transforma fotografia em filme

No modelo contínuo, o cliente não recebe apenas uma etiqueta eterna.

Podemos imaginar:

09:00 RISK = 12

Compra café.

09:17 RISK = 11

Usa o mesmo celular.

12:30 RISK = 10

Compra almoço num estabelecimento habitual.

Tudo normal.

Então:

03:17 NEW DEVICE

Score:

10 -> 22

Logo depois:

PASSWORD RESET

Score:

22 -> 39

Novo beneficiário:

39 -> 58

Transferência incomum:

58 -> 84

Diabolik ainda possui usuário e senha corretos.

O cadastro continua correto.

Mas agora o sistema diz:

IDENTITY = OK

BEHAVIOR = NOT OK

Esse é o coração da mudança.

---

🧮 CAPÍTULO 5 — O Risk Score entra em cena

Para um programador COBOL iniciante, podemos começar pensando em algo simples:

RISK-SCORE = 0

Cada fator acrescenta ou reduz pontos:

IF NEW-DEVICE = 'Y'
   ADD 10 TO RISK-SCORE
END-IF

IF PASSWORD-RESET = 'Y'
   ADD 15 TO RISK-SCORE
END-IF

IF NEW-BENEFICIARY = 'Y'
   ADD 20 TO RISK-SCORE
END-IF

IF UNUSUAL-AMOUNT = 'Y'
   ADD 25 TO RISK-SCORE
END-IF.

Teríamos:

10 + 15 + 20 + 25 = 70

E poderíamos estabelecer:

00-20 LOW
21-40 MEDIUM
41-60 HIGH
61-100 CRITICAL

É apenas um exemplo didático. Um sistema real exigiria muito mais cuidado com pesos, regras, contexto, validação, calibração e governança.

Mas a essência está aqui:

SIGNALS
   ↓
WEIGHTS
   ↓
RULES
   ↓
SCORE
   ↓
DECISION

---

💎 CAPÍTULO 6 — Nem todo diamante vale os mesmos pontos

Aqui Diabolik começa a rir do nosso programa COBOL.

Porque ele percebeu uma fragilidade.

Se nosso modelo simplesmente somar:

NEW DEVICE        +10
PASSWORD RESET    +10
NEW BENEFICIARY   +10
TRANSFER          +10

teremos:

RISK = 40

Mas talvez essa combinação específica represente risco muito maior.

É a diferença entre observar quatro acontecimentos e observar uma história formada por quatro acontecimentos.

Considere:

A = NEW DEVICE
B = PASSWORD RESET
C = NEW BENEFICIARY
D = LARGE TRANSFER

Não podemos assumir sempre que:

RISK(A+B+C+D)
=
RISK(A)+RISK(B)+RISK(C)+RISK(D)

A sequência pode produzir um risco adicional.

Em segurança, contexto importa.

Em fraude, ordem também importa.

---

⏱️ CAPÍTULO 7 — Diabolik conhece o relógio

Imagine:

01/08 NEW DEVICE
15/08 PASSWORD RESET
02/09 NEW BENEFICIARY
15/09 TRANSFER

Pode ser perfeitamente normal.

Agora:

03:17 NEW DEVICE
03:18 PASSWORD RESET
03:20 NEW BENEFICIARY
03:22 TRANSFER

Os eventos são praticamente os mesmos.

Mas o significado mudou completamente.

Entrou uma nova dimensão:

velocity.

Não basta perguntar:

WHAT?

Precisamos perguntar:

WHAT?
WHEN?
HOW OFTEN?
IN WHICH ORDER?

Em sistemas transacionais, tempo também é dado.

---

🧬 CAPÍTULO 8 — O melhor suspeito de João é o próprio João

Agora chegamos ao comportamento.

Imagine que João normalmente faça:

R$ 70
R$ 150
R$ 380
R$ 600
R$ 1.200

Então aparece:

R$ 9.800

Interessante.

Mas Maria administra uma empresa e normalmente movimenta:

R$ 30.000
R$ 70.000
R$ 120.000

Hoje ela movimentou:

R$ 9.800

Se tivermos uma regra burra:

IF AMOUNT > 5000
   HIGH-RISK
END-IF

João e Maria recebem tratamento semelhante.

Mas os comportamentos são completamente diferentes.

O sistema moderno procura estabelecer um baseline.

Ou seja:

como este cliente normalmente se comporta?

Isso permite comparar:

CURRENT BEHAVIOR
       versus
EXPECTED BEHAVIOR

A pergunta deixa de ser:

R$9.800 é muito?

E passa a ser:

R$9.800 é estranho para João?

Isso é muito mais poderoso.

---

🌍 CAPÍTULO 9 — Diabolik viaja rápido demais

Imagine:

20:00 LOGIN SAO PAULO

Depois:

20:35 LOGIN TOKYO

Talvez João tenha descoberto teletransporte.

Talvez seja VPN.

Talvez seja problema na geolocalização.

Talvez sejam sessões diferentes.

Ou talvez tenhamos uma conta comprometida.

Um bom sistema não deveria automaticamente concluir:

FRAUD!

Ele deveria produzir algo semelhante a:

IMPOSSIBLE_TRAVEL +25
NEW_DEVICE        +15
UNKNOWN_IP        +10

E combinar isso com todo o restante.

Essa é outra diferença fundamental.

Sinal não é sentença.

Sinal é evidência.

---

🕸️ CAPÍTULO 10 — O Inspetor Ginko descobre o grafo

Diabolik conseguiu ser perfeito.

Nenhuma transferência parece absurda.

Nenhum login parece impossível.

Nenhuma senha foi redefinida.

Individualmente, cada conta parece normal.

Então entra o equivalente digital do Inspetor Ginko.

Ele deixa de olhar apenas indivíduos e começa a observar relações.

              DEVICE-X
             /    |    \
            /     |     \
         JOAO   MARIA   CARLOS
           |      |       |
        ACCOUNT ACCOUNT ACCOUNT

Interessante.

Três pessoas diferentes utilizam o mesmo dispositivo.

Isso é fraude?

Não necessariamente.

Pode ser uma família.

Pode ser uma empresa.

Pode ser um equipamento compartilhado.

Agora descobrimos:

DEVICE-X
   |
   +--- ACCOUNT-A
   |
   +--- ACCOUNT-B
   |
   +--- ACCOUNT-C
   |
   +--- ACCOUNT-D

E duas dessas contas tiveram fraude confirmada.

A relação ficou mais interessante.

Estamos entrando no mundo de graph analytics.

Clientes, contas, cartões, dispositivos, IPs, telefones, endereços, merchants e beneficiários podem ser representados como nós conectados.

O risco pode estar não apenas no indivíduo.

Pode estar na rede à qual ele pertence.

---

💳 CAPÍTULO 11 — Diabolik entra no BELLACARD

Vamos colocar nosso ladrão dentro de um sistema de cartões.

Diabolik conseguiu utilizar o cartão de João.

Uma autorização chega:

CARD
AMOUNT
MERCHANT
MCC
COUNTRY
TERMINAL
TIMESTAMP

O sistema tradicional verifica:

CARD VALID?
ACCOUNT ACTIVE?
LIMIT AVAILABLE?
CARD BLOCKED?
PIN/CVV VALID?

Mas agora adicionamos:

RISK ENGINE

Arquiteturalmente:

POS / ATM / MOBILE
        |
        v
 TRANSACTION
        |
        v
+----------------+
| AUTHORIZATION  |
+----------------+
        |
   +----+-----+
   |          |
   v          v
ACCOUNT    RISK ENGINE
   |          |
   +----+-----+
        |
        v
 DECISION ENGINE
        |
 +------+------+------+
 |      |      |      |
APPROVE MONITOR VERIFY DECLINE

Agora o Risk Score passa a participar da decisão.

---

🚦 CAPÍTULO 12 — Nem todo suspeito deve ser preso

Essa talvez seja a parte mais importante do conceito inteiro.

Imagine:

RISK 12

Resposta:

APPROVE

Score:

RISK 32

Talvez:

APPROVE + MONITOR

Score:

RISK 54

Talvez:

STEP-UP AUTHENTICATION

Peça biometria.

Confirmação adicional.

MFA.

Outro fator.

Score:

RISK 72

Talvez:

REVIEW

Score:

RISK 96

Talvez:

DECLINE
BLOCK
INVESTIGATE

Perceba a mudança.

Risk Scoring não serve exclusivamente para dizer:

NÃO.

Ele pode ajudar o sistema a decidir quanto de confiança adicional precisa antes de dizer SIM.

---

💰 CAPÍTULO 13 — Prender todo mundo também custa dinheiro

Imagine uma instituição aterrorizada com fraude.

Ela cria:

IF TRANSACTION-AMOUNT > 5000
   DECLINE
END-IF

Fraudes diminuem.

O diretor comemora.

Até aparecer outro relatório:

APPROVAL RATE ↓
CUSTOMER SATISFACTION ↓
REVENUE ↓
ABANDONMENT ↑
SUPPORT CALLS ↑

Descobrimos o false positive.

O cliente era legítimo.

Nosso sistema o tratou como criminoso.

Diabolik escapou enquanto prendíamos João.

É quase poeticamente apropriado.

---

⚖️ CAPÍTULO 14 — O Risk Engine vive entre dois erros

Todo sistema antifraude vive numa tensão.

Se for permissivo demais:

FRAUD ↑
LOSSES ↑

Se for rígido demais:

FALSE POSITIVES ↑
CUSTOMER FRICTION ↑
DECLINES ↑
REVENUE ↓

Então existe uma espécie de equação empresarial:

MAXIMIZE

LEGITIMATE APPROVALS
REVENUE
CUSTOMER EXPERIENCE

MINIMIZE

FRAUD
AML EXPOSURE
CHARGEBACKS
OPERATIONAL COST
REGULATORY RISK

Risk Scoring não elimina essa tensão.

Ele nos permite administrá-la com maior granularidade.

---

🏦 CAPÍTULO 15 — Fraud e AML moram no mesmo prédio, mas não são irmãos gêmeos

Fraude e AML podem utilizar muitos sinais semelhantes:

IDENTITY
TRANSACTIONS
DEVICES
LOCATION
BENEFICIARIES
BEHAVIOR
NETWORK

Mas não são exatamente o mesmo problema.

Fraude normalmente está preocupada com apropriação indevida, engano, abuso de contas, pagamentos ou recursos.

AML olha para riscos associados à movimentação e possível lavagem de recursos, entre outras tipologias de crime financeiro.

Podemos ter:

FRAUD SCORE
     |
     +------+
            |
            v
      COMPOSITE RISK
            ^
            |
     +------+
     |
AML SCORE

A vantagem está em compartilhar sinais sem destruir as particularidades de cada disciplina.

---

🤖 CAPÍTULO 16 — Então chega a Inteligência Artificial

Até aqui podemos fazer muita coisa com regras.

Mas temos milhões de eventos.

Centenas de variáveis.

Relações complexas.

Padrões temporais.

Machine Learning pode ajudar a encontrar combinações que seriam extremamente difíceis de escrever manualmente.

O problema aparece quando recebemos:

MODEL OUTPUT = 97

Perguntamos:

WHY?

E o computador responde metaforicamente:

¯\_(ツ)_/¯

Não.

Ginko não aceitaria.

O auditor muito menos.

Um sistema robusto precisa oferecer reason codes, evidências, rastreabilidade e governança.

Por exemplo:

RISK SCORE = 91

REASONS:

R017 NEW DEVICE
R042 IMPOSSIBLE TRAVEL
R071 UNUSUAL AMOUNT
R103 NEW BENEFICIARY
R121 HIGH VELOCITY

Agora o número possui uma história.

---

🗄️ CAPÍTULO 17 — Ginko entra no Db2

Vamos finalmente entrar no IBM Z.

Podemos imaginar:

CHANNELS
 |
 +-- MOBILE
 +-- WEB
 +-- ATM
 +-- POS
 |
 v
API / MESSAGE LAYER
 |
 v
CICS
 |
 +----------+
 |          |
 v          v
Db2       IBM MQ
 |          |
 |          v
 |       EVENTS
 |          |
 +-----> RISK ENGINE
            |
      +-----+-----+
      |     |     |
    RULES  ML   GRAPH
      |     |     |
      +-----+-----+
            |
            v
        RISK SCORE
            |
            v
      DECISION ENGINE

O detalhe crucial:

o cliente está esperando.

No supermercado, João não quer assistir a uma arquitetura de 47 microsserviços discutindo se deve aprovar seu café.

Ele quer:

BIP!
APROVADO

Portanto latência importa.

Muito.

---

⚡ CAPÍTULO 18 — O roubo perfeito dura milissegundos

Uma transação online pode precisar executar diversas verificações:

CARD VALIDATION
ACCOUNT LOOKUP
LIMIT CHECK
STATUS CHECK
FRAUD RULES
RISK SCORE
AUTHORIZATION
LOGGING

Tudo dentro de um orçamento de latência.

Essa é uma das razões pelas quais a arquitetura de sistemas críticos é tão fascinante.

Não basta calcular corretamente.

Precisamos calcular corretamente a tempo.

O Risk Engine que responde depois que a transação terminou é como Ginko chegando ao cofre na manhã seguinte.

Interessante para investigação.

Inútil para impedir aquele evento.

---

🧯 CAPÍTULO 19 — O sistema também precisa investigar a si mesmo

Imagine uma nova regra.

Ela bloqueia 40% das transações de determinado segmento.

Fraude cai 2%.

Parece bom?

Talvez não.

Precisamos observar:

APPROVAL RATE
DECLINE RATE
FRAUD RATE
FALSE POSITIVE RATE
CHARGEBACK RATE
CHALLENGE RATE
MANUAL REVIEW RATE

Também:

RULE HIT RATE
SCORE DISTRIBUTION
REASON CODES

E algo que considero particularmente interessante:

SCORE MIGRATION

Quem passou:

LOW -> MEDIUM

Quem passou:

MEDIUM -> HIGH

E principalmente:

LOW -> CRITICAL

O valor não está somente em descobrir quem está perigoso.

Está em descobrir quem está mudando rapidamente.

---

⌛ CAPÍTULO 20 — Até suspeitas envelhecem

João viajou.

Usou um novo dispositivo.

Fez uma transação diferente.

Seu score subiu:

RISK = 68

Depois voltou para casa.

Utilizou normalmente sua conta por semanas.

Nada estranho aconteceu.

Deveria continuar em 68 para sempre?

Provavelmente não.

Podemos introduzir o conceito de risk decay.

Conforme o tempo passa sem novos sinais relevantes:

68
 |
 v
55
 |
 v
41
 |
 v
28

Isso impede que eventos antigos se transformem em condenações eternas.

Tempo não serve apenas para aumentar risco.

Também pode ajudar a contextualizá-lo.

---

🎯 CAPÍTULO 21 — O Risk Score também pode ser atacado

Aqui Diabolik percebe outra coisa.

Se conseguir descobrir as regras, poderá tentar permanecer abaixo dos thresholds.

Suponha:

R$10.000 = HIGH RISK

Então ele tenta:

R$4.800
R$4.700
R$4.900

Uma regra olha para cada evento:

OK
OK
OK

Um sistema contextual observa:

3 TRANSACTIONS
SHORT WINDOW
TOTAL R$14.400
UNUSUAL VELOCITY

E responde:

RISK ↑

Isso nos ensina outra coisa importante:

fraudadores também observam sistemas antifraude.

O Risk Engine não enfrenta um fenômeno estático.

Existe um adversário adaptativo do outro lado.

---

🧪 CAPÍTULO 22 — Champion contra Challenger

Se alterarmos um modelo de risco diretamente em produção, podemos criar nosso próprio desastre.

Então imagine:

CHAMPION MODEL

É o modelo atualmente utilizado.

Ao lado:

CHALLENGER MODEL

O challenger pode receber os mesmos eventos sem necessariamente controlar a decisão final.

Depois comparamos:

FRAUD DETECTION
FALSE POSITIVES
APPROVAL RATE
LATENCY
STABILITY

Se realmente for melhor, pode tornar-se o novo champion.

Isso transforma Risk Scoring em processo de engenharia, e não numa coleção de palpites.

---

🧾 CAPÍTULO 23 — Diabolik odeia auditoria

Imagine que seis meses depois alguém pergunte:

Por que a transação 918273 foi recusada?

Não podemos responder:

Porque o score estava alto.

Precisamos conseguir reconstruir:

TRANSACTION
MODEL VERSION
RULE VERSION
INPUT DATA
SCORE
REASON CODES
DECISION
TIMESTAMP

Idealmente:

03:17:01 EVENT RECEIVED
03:17:01 DEVICE RULE HIT
03:17:01 VELOCITY RULE HIT
03:17:01 SCORE 82
03:17:01 STEP-UP REQUESTED
03:17:04 MFA FAILED
03:17:04 DECLINED

Isso é auditabilidade.

E em sistemas financeiros ela não é decoração arquitetural.

É parte do produto.

---

🕵️ CAPÍTULO 24 — A máquina encontra a pista; Ginko monta o caso

Automação não significa necessariamente remover o investigador.

Significa evitar que ele desperdice seu tempo procurando palha.

Imagine um analista recebendo:

CASE 827364

CUSTOMER: JOAO
RISK: 93

TRIGGERS:
NEW DEVICE
PASSWORD RESET
NEW BENEFICIARY
UNUSUAL TRANSFER
SHARED DEVICE

RELATED:
7 ACCOUNTS

CONFIRMED FRAUD:
2 ACCOUNTS

Agora existe um caso investigável.

A máquina percorreu milhões de eventos.

O humano recebeu uma exceção relevante.

MACHINE
   |
   v
DETECT
   |
   v
CORRELATE
   |
   v
PRIORITIZE
   |
   v
HUMAN INVESTIGATION

Essa parceria é muito mais interessante do que a fantasia de simplesmente substituir todo investigador por IA.

---

💎 CAPÍTULO 25 — Finalmente Diabolik chega ao cofre

Às 03:17, Diabolik inicia sua operação.

Primeiro:

LOGIN

Nada acontece.

Depois:

NEW DEVICE

Pequena alteração.

Depois:

PASSWORD RESET

Outra alteração.

Depois:

NEW BENEFICIARY

O sistema começa a ficar desconfiado.

Finalmente:

TRANSFER R$ 48.000

O antigo sistema talvez enxergasse:

JOAO
KYC OK
ACCOUNT ACTIVE
BALANCE AVAILABLE

O novo sistema enxerga:

JOAO
+
NEW DEVICE
+
PASSWORD RESET
+
NEW BENEFICIARY
+
UNUSUAL AMOUNT
+
HIGH VELOCITY
+
BEHAVIORAL DEVIATION

Resultado:

RISK SCORE = 94

Decision Engine:

STEP-UP AUTHENTICATION

Diabolik possui usuário.

Possui senha.

Possui dados pessoais.

Mas falta alguma coisa que João possui.

A operação falha.

Não porque o sistema descobriu:

Este homem é Diabolik.

Isso seria impossível.

Ele descobriu algo muito mais útil:

Quem quer que esteja realizando esta operação não está se comportando como João.

Esse é o verdadeiro poder da análise comportamental.

---

🐣 EASTER EGG — 03:17

Quem já visitou algumas vezes o Bellacosa Mainframe percebeu.

Algo sempre acontece às:

03:17

É o horário em que ninguém deveria estar olhando.

O batch está trabalhando.

O operador tomou café.

O desenvolvedor jurou que não mexeu em produção.

E algum JOB misterioso aparece:

JOBNAME  DIABOLIK
OWNER    UNKNOWN
STATUS   EXECUTING

Ginko abre o SDSF.

Procura o JOB.

Nada.

Só encontra no SYSOUT:

ICH408I
USER(DIABOLIK) ACCESS DENIED

Desta vez, RACF ganhou.

☕

---

🧠 CAPÍTULO 26 — O que o programador COBOL iniciante precisa guardar

Depois de toda essa perseguição, podemos reduzir o Risk Scoring a uma cadeia bastante compreensível:

RECEIVE EVENT
     |
     v
IDENTIFY CUSTOMER
     |
     v
LOAD CONTEXT
     |
     v
READ HISTORY
     |
     v
CALCULATE SIGNALS
     |
     v
APPLY RULES
     |
     v
CALCULATE SCORE
     |
     v
MAKE DECISION
     |
     v
LOG EVERYTHING

Veja que curioso.

Quando retiramos os nomes modernos, aparecem conceitos conhecidos:

INPUT
VALIDATION
LOOKUP
BUSINESS RULE
CALCULATION
DECISION
AUDIT
COMMIT

O programador COBOL de 1985 reconheceria boa parte da lógica.

O que mudou foi a quantidade de contexto disponível e a velocidade necessária para correlacioná-lo.

Hoje podemos acrescentar:

DEVICE
IP
LOCATION
BEHAVIOR
VELOCITY
GRAPH
ML
REAL-TIME EVENTS

Mas o problema fundamental continua lindamente familiar:

DADOS
  +
REGRAS
  +
CONTEXTO
  =
DECISÃO

---

☕ EPÍLOGO — Ginko nunca precisou saber quem estava atrás da máscara

Essa talvez seja a grande lição de Risk Scoring.

O modelo antigo queria classificar pessoas:

LOW
MEDIUM
HIGH

O modelo moderno procura compreender situações:

CUSTOMER
+
TRANSACTION
+
DEVICE
+
LOCATION
+
TIME
+
BEHAVIOR
+
HISTORY
+
RELATIONSHIPS

E calcula novamente quando o contexto muda.

Isso muda também a relação entre segurança e negócio.

Um bom cliente realizando uma operação compatível com seu comportamento pode receber menos atrito.

Uma pequena anomalia pode receber monitoramento.

Uma situação intermediária pode receber autenticação adicional.

Uma sequência altamente suspeita pode ser bloqueada ou enviada para investigação.

Portanto:

RISK ≠ BLOCK

Risk é informação para decidir qual controle é proporcional à situação.

É isso que torna o Risk Scoring moderno tão interessante para fintechs, bancos, adquirentes, sistemas de cartões e arquiteturas de pagamentos.

A missão não é bloquear o maior número possível de transações.

É algo muito mais difícil:

bloquear Diabolik sem impedir João de comprar o jantar.

E existe uma ironia maravilhosa nisso.

Diabolik passou décadas aperfeiçoando máscaras, identidades falsas, disfarces e planos perfeitos.

No mundo digital, porém, talvez ele encontre um adversário diferente.

Não uma câmera procurando seu rosto.

Não um policial procurando seu nome.

Não um cadastro perguntando quem ele diz ser.

Mas um Risk Engine silencioso perguntando:

Você possui as credenciais de João.

Você conhece os dados de João.

Você entrou na conta de João.

Mas...

por que não está se comportando como João?

No outro lado da tela, Ginko sorri.

O RISK-SCORE muda:

17
29
46
68
94

Diabolik aperta ENTER.

O mainframe responde:

TRANSACTION DECLINED

REASON:
BEHAVIORAL RISK

RETURN-CODE: 08

E em algum lugar do data center, provavelmente ao lado de um programa COBOL que ninguém ousa recompilar desde 1997, o JOB continua EXECUTING.

Porque no Risk Scoring moderno, o crime perfeito não precisa deixar uma impressão digital.

Basta deixar uma anomalia. ☕🕶️💻