Contenuto realizzato con il supporto di strumenti di intelligenza artificiale e revisionato dall'autore.
Il messaggio sembrava autentico. Mittente: il nome della banca. Testo: un avviso urgente su un accesso sospetto al conto, con invito a chiamare un numero per "bloccare la situazione". La ricorrente chiama, segue le istruzioni dell'interlocutore, installa l'applicazione indicata — apparentemente identica a quella ufficiale — e nel giro di ore si ritrova con un bonifico non autorizzato di €8.820 eseguito a sua insaputa. Questo è il caso deciso dall'ABF Napoli con la decisione n. 797 del 28 gennaio 2026 (Pres. Carriero, Rel. Gigliotti), che ha ripartito la responsabilità per smishing e rimborso banca in misura paritaria, 50% a ciascuno. Una pronuncia che non assolve né condanna integralmente nessuno, e proprio per questo merita un'analisi attenta: perché stabilisce una soglia, non un'assoluzione.
Il quadro normativo: la banca non si libera con la sola SCA
Il punto di partenza è l'art. 10 del D.lgs. n. 11/2010, come modificato dal D.lgs. n. 218/2017 in recepimento della direttiva PSD2. Ai sensi dell'art. 10, comma 1, del D.lgs. n. 11/2010, qualora l'utente di servizi di pagamento neghi di aver autorizzato un'operazione già eseguita, è onere del prestatore di servizi di pagamento provare che l'operazione è stata autenticata, correttamente registrata e contabilizzata e che non ha subito le conseguenze del malfunzionamento delle procedure necessarie per la sua esecuzione. Ma non è tutto. L'art. 10, comma 2, del D.lgs. n. 11/2010 pone a carico del prestatore del servizio di pagamento l'onere di fornire la prova della frode, del dolo o della colpa grave dell'utente.
Questo significa che la banca non può limitarsi a produrre i log di autenticazione e dire: "il PIN è stato inserito correttamente, quindi l'operazione è autorizzata". L'utilizzo di uno strumento di pagamento registrato dal PSP non è di per sé necessariamente sufficiente a dimostrare che l'operazione sia stata autorizzata dall'utente medesimo. Il Collegio precisa che l'utente può disconoscere un'operazione anche quando il processo di pagamento si sia svolto in modo formalmente regolare: la corretta validazione delle credenziali utente non accerta se queste siano state apposte da un hacker o effettivamente dal cliente.
Nel caso ABF Napoli n. 797/2026, l'intermediario si era costituito eccependo la colpa grave della cliente, sul presupposto che l'operazione contestata risultava correttamente autenticata mediante Strong Customer Authentication — SCA (inserimento di PIN su device certificato e ID biometrico) — e che la ricorrente aveva volontariamente seguito le istruzioni del frodatore installando il programma malevolo. Il Collegio ha preliminarmente richiamato il quadro normativo applicabile — D.lgs. n. 11/2010, come modificato dal D.lgs. n. 218/2017 in recepimento della PSD2 — ribadendo che la responsabilità del prestatore di servizi di pagamento è esclusa solo quando questi abbia dato prova di aver utilizzato meccanismi di autenticazione forte e dimostrato una condotta dolosa.
La banca aveva implementato la SCA: PIN e notifica push. Aveva quindi adempiuto a una parte del proprio obbligo. Ma non aveva rilevato — né segnalato alla cliente — l'anomalia costituita dall'accesso al conto tramite un'app clonata. Questo è il punto critico su cui si incardina il concorso di colpa.
Perché installare un'app malevola non è (sempre) colpa grave
La distinzione tra colpa semplice e colpa grave è il terreno su cui si gioca la partita nei ricorsi per frode informatica e bonifico non autorizzato. La colpa grave presuppone una negligenza inescusabile, una violazione degli standard minimi di prudenza che chiunque potrebbe rispettare. L'ABF Napoli n. 797/2026, accogliendo parzialmente il ricorso, ha implicitamente ritenuto che l'installazione di un'app indistinguibile da quella ufficiale, a seguito di un SMS che replicava fedelmente la grafica e il mittente della banca, non integrasse di per sé quella soglia di negligenza inescusabile.
Nel caso di specie, la ricorrente aveva ricevuto un SMS apparentemente proveniente dal servizio clienti dell'intermediario, che la invitava a contattare un numero telefonico per aggiornare i propri dati. L'interlocutore la induceva a installare una nuova app token, apparentemente identica a quella ufficiale, che in realtà era un'applicazione malevola in grado di consentire l'accesso remoto al conto corrente.
In questo scenario, la sofisticazione dell'attacco — SMS spoofing con mittente falsificato, clone visivamente perfetto dell'app, operatore che simula il supporto clienti — abbassa la soglia di imputabilità soggettiva della vittima. Questa ricostruzione mette in crisi l'equazione apparentemente più semplice: credenziali corrette uguale operazione autorizzata. Una sottrazione delle credenziali ottenuta attraverso tecniche sofisticate di smishing e malware non permette di concludere automaticamente che la vittima abbia agito con colpa grave.
Tuttavia, il Collegio non ha ritenuto di poter esonerare del tutto la cliente. L'aver seguito istruzioni di un interlocutore sconosciuto per installare un'applicazione esterna ai canali ufficiali — anche se l'inganno era raffinato — costituisce pur sempre un contributo causale alla produzione del danno. Da qui la ripartizione al 50%. Il risultato pratico: la banca deve rimborsare €4.410 anziché €8.820.
Questa soluzione intermedia non è casuale. Riflette una tensione reale nell'interpretazione dell'art. 10 D.lgs. 11/2010: da un lato, il D.lgs. n. 11/2010 come modificato ha configurato una responsabilità contrattuale connotata da un regime di speciale protezione e di altrettanto favor probatorio per l'utente, con un assetto probatorio particolarmente gravoso per il professionista; dall'altro, la norma non trasforma la banca in assicuratore incondizionato di qualsiasi perdita subita dal correntista.
La tendenza giurisprudenziale più recente sembra però orientarsi verso una protezione più ampia della vittima di frode, almeno quando l'attacco è particolarmente sofisticato. Con la sentenza n. 1929/2026, la Terza Sezione Civile della Corte d'Appello di Palermo ha respinto integralmente l'appello della banca, confermando la condanna al rimborso integrale. In quel caso, la frode era stata resa possibile da una campagna malevola nota come "BRATA": gli autori avevano indotto la vittima a scaricare un'applicazione fraudolenta tramite un link presentato come proveniente dalla banca, sottraendo così le credenziali. La consulenza tecnica disposta in giudizio aveva evidenziato che la transazione contestata proveniva da un indirizzo IP mai utilizzato in precedenza dal cliente, e che nello stesso giorno il sistema della banca aveva già bloccato altri tentativi di accesso ritenuti sospetti. L'elemento determinante in quel caso è stato proprio la prova che il sistema di sicurezza bancario aveva già rilevato anomalie e non le aveva comunicate o gestite: circostanza che mancava, almeno in parte, nel caso deciso dall'ABF Napoli.
La responsabilità del cliente può configurarsi quando l'utilizzatore comunichi volontariamente le proprie credenziali a terzi, ma non quando sia vittima di una sottrazione fraudolenta realizzata mediante tecniche evolute di smishing e malware. Il confine, dunque, non è tanto sull'installazione dell'app, quanto sul grado di sofisticazione dell'inganno subito e — sul versante bancario — sull'adeguatezza dei sistemi di alert e anomaly detection.
Il dato di sistema è preoccupante: la Relazione annuale ABF 2025, presentata il 24 giugno 2026, segnala che i ricorsi per frodi su pagamenti sono cresciuti del 21% rispetto all'anno precedente e rappresentano ormai il 37% del contenzioso totale dinanzi all'Arbitro. Non si tratta di fenomeni episodici, ma di una vulnerabilità strutturale del rapporto banca-cliente nell'era dei pagamenti digitali.
Come recita il brocardo vigilantibus iura subveniunt: il diritto soccorre chi veglia. Ma questa massima va letta in modo bilaterale: deve vegliare il cliente, certo, ma deve vegliare anche — e forse di più — il soggetto professionale che gestisce il denaro altrui e dispone degli strumenti tecnici per intercettare le anomalie.
Come scriveva Norberto Bobbio, "la regola non esaurisce il diritto: è nell'applicazione della regola al caso concreto che si misura la giustizia". ABF Napoli n. 797/2026 lo dimostra bene: la norma c'è, chiara, ma la sua applicazione al caso concreto dipende da quante variabili vengono valutate — la sofisticazione dell'attacco, la reattività del sistema bancario, il comportamento della vittima. Non esiste una risposta automatica alla domanda "mi rimborsa la banca?". Esiste invece un percorso, che vale la pena conoscere.
Se sono vittima di smishing, la banca deve rimborsarmi? Come funziona il ricorso ABF?
La risposta breve è: dipende dal grado di sofisticazione dell'attacco e dalla condotta della banca. La risposta lunga è quella che questa pronuncia illustra. In ogni caso, è fondamentale agire subito: appena ci si accorge di un bonifico non autorizzato, occorre disconoscere l'operazione per iscritto alla banca (meglio tramite PEC o raccomandata, per avere data certa), sporgere denuncia-querela all'autorità giudiziaria o alla Polizia Postale, e conservare tutto — SMS ricevuti, screenshot dell'app installata, registrazioni se disponibili, cronologia delle chiamate.
Il reclamo alla banca è il primo passaggio obbligatorio per accedere all'ABF, Arbitro Bancario Finanziario: senza di esso, il ricorso è improcedibile. La banca ha 30 giorni per rispondere al reclamo (15 giorni per i servizi di pagamento). Se non risponde o risponde in modo insoddisfacente, si può presentare ricorso all'ABF competente per territorio. Il procedimento è gratuito per il cliente e si conclude mediamente entro 90-120 giorni. Se la banca respinge il reclamo, resta la via dell'Arbitro Bancario Finanziario e, in ultima istanza, quella giudiziale.
Quando scatta la colpa grave che esime la banca dal rimborso? Secondo l'orientamento prevalente, quando il cliente ha comunicato consapevolmente le proprie credenziali a terzi, ha ignorato avvisi di sicurezza espliciti della banca, ha installato applicazioni da fonti palesemente non ufficiali senza alcuna pressione esterna. Non è colpa grave, invece, cedere a un inganno altamente sofisticato che replica fedelmente i canali ufficiali della banca, specie se — come nel caso ABF Napoli 797/2026 — il sistema bancario non ha rilevato né segnalato le anomalie tecniche che avrebbero dovuto bloccare l'operazione.
Il punto di riflessione che questa decisione lascia aperto è uno solo, ma dirimente: un intermediario che implementa la SCA e poi non monitora in modo efficace gli accessi da device non censiti o da app clonate sta adempiendo alla lettera della PSD2 ma non al suo spirito. La linea interpretativa che si va consolidando, a partire dal dato normativo di cui agli artt. 10 e 11 del D.lgs. n. 11/2010, impone al prestatore di servizi di pagamento un onere probatorio rafforzato. Provare l'autenticazione formale è necessario, ma non sufficiente: occorre anche dimostrare che il sistema di sicurezza era adeguato al livello di rischio concreto del caso specifico. È su questo secondo livello di prova che molte banche continuano a non reggere il confronto con la complessità degli attacchi reali.
Redazione - Staff Studio Legale MP
