Antifrode con machine learning: rilevare comportamenti anomali in tempo reale

Di Luca Ferri, Head of Risk Analytics • Ultimo aggiornamento: 26 marzo 2026 • Lettura: 12–14 minuti

Ore 02:17. Un alert che non doveva arrivare

La notte è silenziosa. Il pager vibra. Cinque transazioni in 8 secondi. Stesso device, sette BIN diversi. Importi piccoli, sotto soglia. Il grafico dei tentativi sale a scatti. Lo scoring rientra in 32 ms. Il sistema alza la mano. Non è un falso allarme. È un test di una banda che sonda i nostri limiti.

In quei momenti, vince chi legge il contesto più in fretta. Non basta una regola “se X allora blocca”. Serve un motore che capisca segnali deboli, lega identità e tempo, e decide cosa fare, subito. Questo richiede un disegno chiaro del rischio. Il framework di gestione del rischio AI del NIST aiuta a mettere ordine: obiettivi, controlli, misure, revisione.

Cos’è “frode” oggi: oltre il chargeback

La frode non è solo una carta rubata. Abbiamo account takeover, abuso di bonus, triangolazione con wallet, reti di account “mule”, e “friendly fraud” con contestazioni tardive. Il danno vero non è solo il tasso di frode. È anche il costo dei falsi positivi: clienti buoni rifiutati, reclami, campagne rovinate.

Il quadro delle minacce cambia in fretta. Vale tenere d’occhio le minacce emergenti nell’AI tracciate da ENISA. Gli attori malevoli studiano i nostri flussi. Provano schemi lenti, diffusi, con importi bassi. Cercano segnali che noi non guardiamo.

Regole e ML insieme, non uno al posto dell’altro

Le regole servono per “hard fail” chiari (es. carta in blacklist, documento falso). Il machine learning serve per legare segnali deboli: velocità, entropia, vicinanza tra identità. Lo schema vincente è ibrido. Regole pulite per conformità e blocchi certi. Modelli per il “grigio”. Un motore di decisione unisce tutto.

Tre pattern pratici:

• Supervised + regole: il modello stima il rischio; le regole alzano o abbassano la soglia.
• Unsupervised in pre‑filtro: si scartano outlier sporchi prima del modello finale.
• Grafo come arricchimento: relazioni tra email, telefono, device, IBAN rendono visibile la rete.

Vuoi vedere un esempio di pipeline? Ecco una architettura frodi real‑time su Google Cloud. Preferisci AWS? C’è anche una soluzione real‑time pre‑costruita con componenti riutilizzabili.

Quale metodo usare, quando: una tabella onesta

Non esiste un algoritmo “migliore in assoluto”. La scelta dipende da dati, latenza e spiegabilità. La tabella qui sotto aiuta a decidere in modo rapido.

Regressione logistica (supervised)	Transazioni tabellari	5–20 ms	Veloce, interpretabile	Non‑linearità limitate	Pagamenti carta, SCA step‑up
Random Forest / Gradient Boosting	Tabellari ricchi	10–40 ms	Ottimo su tabellari	Rischio overfit, tuning	Account takeover, chargeback
Autoencoder (unsupervised)	Dati ad alta dimensione	10–30 ms	Trova anomalie nuove	Spiegabilità minore	Bonus abuse, bot detection
Isolation Forest	Tabellari / stream	5–15 ms	Leggero, robusto	Sensibile a scaling	AML “light”, velocity checks
GNN (graph‑based)	Relazioni tra identità	30–80 ms (con cache)	Smonta reti e collusioni	Più complesso e costoso	Ring fraud, affiliazioni sospette
HMM / LSTM su sequenze	Eventi nel tempo	20–60 ms	Capta pattern temporali	Drift rapido, cura dati	Sessioni, salti di device

Per uno sguardo ampio su anomalie in flusso, utile questa survey arXiv sul rilevamento di anomalie su stream. Chiarisce dove hanno senso metodi non supervisionati.

L’architettura che regge i millisecondi

Servono pochi passaggi, molto curati. Ingest con Kafka o Kinesis. Stream processing con Flink o Spark. Un feature store doppio (online e offline), ad esempio Feast. Un servizio di modelli a bassa latenza (Vertex AI, SageMaker o MLflow+Triton). Un motore di regole, una cache calda (Redis), e un livello di decisione che unisce tutto.

In molti casi basta una Kappa Architecture (solo stream). In altri serve una Lambda (batch + stream) per avere storia profonda e feature fresche. La chiave è fissare un budget di latenza p95. Esempio: 50 ms totali. 10 ms ingest, 15 ms feature, 15 ms modello, 10 ms regole + I/O. Tenerne il conto in ogni rilascio.

Se lavori su Azure, guarda l’approccio a anomaly detection in streaming. Per sicurezza e audit, allinea i controlli con il NIST SP 800‑53. Aiuta a mappare accessi, logging, segregazione dei ruoli.

Le feature che contano (e quelle che fanno danno)

Le feature buone vincono le frodi. Alcuni esempi che rendono subito:

• Velocity: numero di tentativi e spesa in Δt per utente, device, IP.
• Entropia IP e ASN: quanta varietà nelle fonti? Tor e VPN alzano il rischio.
• Time‑to‑first‑loss: quanto presto un nuovo utente genera perdita.
• Fingerprint del device: mix di canvas, timezone, lingua, RAM.
• Edit distance su indirizzi e nomi simili per trovare varianti furbe.
• Grafo identità: legami tra email, telefono, IBAN, carta, indirizzo.

Evita leakage: niente feature che usano eventi futuri. Correggi per stagionalità. Bucketizza con cura per ridurre rumorosità. Per logging e telemetria, buone linee guida nei whitepaper SANS su best practice.

iGaming: schemi che cambiano ogni notte

Nell’iGaming i pattern ruotano veloce. Vedi multi‑account per catturare bonus. Collusione nei giochi P2P con puntate bilanciate. Bot su slot con micro‑puntate. Triangolazioni con wallet e carte prepagate.

Cosa funziona in campo:

• Device binding “soft”: non blocca al primo cambio, ma pesa nella scorecard.
• Regole adattive per le promo: limiti progressivi, soglie che seguono la campagna.
• Grafo per cluster sospetti: trova nodi che usano stessa carta, IP o device.
• Human‑in‑the‑loop: coda review per casi al margine, con spiegazioni chiare.

Per chi vuole scegliere operatori seri e trasparenti, una risorsa utile è NorskCasino guide, con criteri chiari su KYC, pagamenti, e pratiche di gioco responsabile. Nota editoriale: potremmo ricevere una commissione se visiti partner citati; le valutazioni restano indipendenti e basate su criteri pubblici.

Metriche che muovono il business

AUC e ROC vanno bene per confronto. Ma in produzione contano altre cose: perdita attesa evitata, tasso di approvazione, WDR (wrongly declined rate), reclami per 1000 transazioni, LTV salvato. Le soglie non sono statiche: cambiano per ora del giorno, per campagna, per canale.

Usa test “champion‑challenger” e monitora l’impatto. Guardare come lo fa un attore dei pagamenti aiuta: qui una panoramica su prevenzione frodi nei pagamenti con Stripe Radar.

Addestramento, sbilanciamento e drift

I dati frode sono sbilanciati. Non serve forzare SMOTE a caso. Meglio pesi di classe, focal loss, e campioni puliti. Le etichette arrivano tardi (es. chargeback). Quindi serve un “golden set” valido nel tempo e un piano di aggiornamento.

Drift dei dati e del concetto sono diversi. Il primo è cambio di distribuzioni. Il secondo è cambio del rapporto tra feature e frode. Tieni alert separati per entrambi. Fai retraining cadenzato. Rilascia con canary e rollback pronto.

Per il lato fiducia e governance, è utile il lavoro del WEF su come costruire fiducia nei sistemi di AI. Ricorda: fiducia non è un banner, è routine di lavoro.

Quando l’attaccante studia il tuo modello

Chi attacca prova a saggiare le soglie. Cambia un campo alla volta. Trova cluster “morbidi”. Questo è model probing. Contromisure: rate‑limit, randomizza un piccolo set di feature, usa ensemble con comportamenti diversi, inserisci honeypot (es. offerte che attirano bot).

Occhio anche al poisoning: dati falsi in feedback. Chi controlla l’etichetta? Tieni audit, firma dei dataset, e tripwire su feature chiave.

Governance, privacy, trasparenza

Le decisioni automatizzate toccano diritti reali. L’Art. 22 GDPR è centrale. Per chiarimenti, leggi le linee guida EDPB su decisioni automatizzate. La regola base: supervisione umana, spiegazione chiara, possibilità di contestare.

La guida dell’ICO su AI e decisioni automatizzate è pratica: minimizza i dati, controlla bias, tieni registro dei test.

Nei pagamenti, PSD2 spinge l’autenticazione forte. Mantenere frizione bassa e rischio basso è arte e metodo. Riferimento ufficiale: PSD2 e SCA.

Per identità e antiriciclaggio, vedi il lavoro FATF su identità digitale e AML. Qui il grafo identità torna oro, ma con privacy by design.

Messa in produzione e osservabilità

Definisci SLO chiari: p95 < 50 ms, disponibilità 99.9%, tempi di review, soglie di drift. Metti gate di qualità dati: schema, valori, freschezza. Se un controllo fallisce, il sistema deve degradare in modo sicuro (fallback a regole o limiti stretti).

Traccia log, metriche e trace. Tieni un playbook per incidenti, con ruoli e tempi. Per spunti operativi, i playbook di risposta agli incidenti di SANS sono un buon inizio.

Quattro errori che vedo troppo spesso

• Leakage nelle feature (dati futuri nel training).
• Validazione non temporale su dati sequenziali.
• Feedback loop: il modello allena se stesso su casi filtrati.
• Test senza periodi di picco e promo: poi in produzione salta tutto.

Checklist pronta all’uso

• Dati minimi: ID utente, device, IP/ASN, metodo pagamento, importo, tempo, esito.
• Feature chiave: velocity su utente/device/IP, entropia IP, indicatori di grafo, distanza indirizzi.
• Architettura: ingest → feature store online/offline → serving modello → regole → decisione → coda manuale.
• Metriche business: WDR, approval rate, perdita evitata, reclami.
• Governance: DPIA, Art. 22, explainability (SHAP per locale, importanza globale), audit trail.
• Operatività: SLO p95, drift alerts, data quality gates, canary, rollback.
• Piano A/B: champion‑challenger continuo, soglie dinamiche per ora/canale.
• Fallback: profili di rischio statici e limiti transitori in caso di guasto.

Glossario rapido

• Anomaly detection: metodi che trovano deviazioni dal comportamento normale.
• Feature store: servizio che serve feature pronte, sia in batch che in tempo reale.
• Drift: cambio nel tempo dei dati o del rapporto dati‑esito.
• Grafo: modello che rappresenta entità e legami tra esse.
• p95: valore sotto cui cade il 95% delle latenze.

FAQ

Chi firma

Luca Ferri è Head of Risk Analytics. Da 10 anni costruisce sistemi antifrode per pagamenti, iGaming e retail. Ha parlato a RiskTech Europe e ML Ops Summit. Certificazioni: GCP Professional ML Engineer, AWS ML Specialty. LinkedIn.

Politica editoriale: revisione contenuti ogni trimestre. Segnalazioni e fonti vengono verificate. Disclosure su affiliazioni quando presenti.