Come le banche moderne gestiscono il traffico del Black Friday senza mandare l’app in crash?

“Pagamento rifiutato”. Due parole che, durante il picco di acquisti del Black Friday, possono trasformarsi in una perdita secca di fatturato e in un danno d’immagine irreparabile. Per un utente business, l’affidabilità dei servizi bancari non è un’opzione, ma il fondamento su cui si regge l’operatività quotidiana. Quando l’app della banca va in crash o il POS smette di funzionare, la colpa viene spesso attribuita a un generico “sovraccarico dei server”, una spiegazione tanto comune quanto semplicistica. La realtà è molto più complessa e affonda le sue radici nelle fondamenta stesse dell’infrastruttura tecnologica che governa i nostri soldi digitali.

Il vero divario non è tra “vecchio” e “nuovo”, ma tra due filosofie architettoniche opposte: da un lato, sistemi monolitici che portano con sé decenni di “debito tecnico”; dall’altro, architetture distribuite, elastiche e resilienti per progettazione. La capacità di una banca di restare operativa durante l’assalto delle tredicesime o dei saldi non dipende dalla semplice potenza di calcolo, ma da come questa potenza è orchestrata. La differenza la fanno concetti come i microservizi, la scalabilità elastica, la ridondanza geografica e metriche precise come RTO e RPO.

Questo articolo non si limita a constatare il problema, ma lo smonta pezzo per pezzo dal punto di vista di un ingegnere infrastrutturale. Analizzeremo perché la vecchia banca tradizionale fatica a tenere il passo, quali sono le garanzie tecniche che un’azienda deve pretendere dal proprio fornitore di servizi finanziari e come le strategie mutuate dai giganti del tech, come Netflix, stiano ridefinendo il concetto di affidabilità nel settore bancario. Comprendere questa ingegneria invisibile è l’unico modo per scegliere un partner finanziario che non ti abbandoni proprio nel momento del bisogno.

In questo approfondimento, analizzeremo le architetture tecnologiche che determinano la stabilità dei servizi bancari, offrendo una visione chiara delle soluzioni che garantiscono operatività continua. Scopri come navigare le complessità del banking moderno per assicurare la resilienza del tuo business.

Perché la tua vecchia banca va offline ogni primo del mese e le neobanche no?

Il disservizio che colpisce l’internet banking di una banca tradizionale all’inizio del mese, durante l’accredito degli stipendi, non è un caso, ma un sintomo di un’architettura datata. Questi sistemi, spesso definiti “monolitici”, funzionano come un unico, enorme blocco di codice. Se una singola componente va sotto stress, l’intero sistema rischia di crollare. L’episodio del Black Friday 2024 è emblematico: un guasto alla rete di Worldline ha paralizzato i pagamenti in tutta Italia, con perdite stimate di 100 milioni di euro per i commercianti, dimostrando la fragilità di un’infrastruttura centralizzata.

Le neobanche, al contrario, nascono su un paradigma diverso: i microservizi. In questa architettura, l’applicazione è scomposta in tanti piccoli servizi indipendenti (gestione conti, pagamenti, notifiche). Se il servizio delle notifiche ha un problema, quello dei pagamenti continua a funzionare perfettamente. Le differenze chiave sono tre:

• Architettura a silos vs. Microservizi: Le banche legacy hanno sistemi separati (conti, mutui, investimenti) che comunicano a fatica tramite processi notturni (“batch”). Le neobanche usano microservizi che dialogano in tempo reale e possono essere aggiornati o potenziati singolarmente.
• Debito tecnico COBOL vs. Codice moderno: Una porzione significativa del core banking, anche in Italia, si basa ancora su codice COBOL scritto negli anni ’80 per mainframe. Questo “debito tecnico” rende ogni modifica lenta, costosa e rischiosa. Le challenger bank utilizzano linguaggi e protocolli moderni (API RESTful) nativamente flessibili.
• Scalabilità manuale vs. Elastica: Per gestire picchi prevedibili come le tredicesime, le banche tradizionali devono pianificare un potenziamento manuale dei server con settimane di anticipo (capacity planning). Le architetture cloud-native delle neobanche, invece, scalano in modo elastico e automatico: le risorse aumentano in pochi secondi per gestire il picco e diminuiscono subito dopo, ottimizzando i costi.

In sintesi, la stabilità non è questione di fortuna, ma di progettazione. Un’architettura a microservizi è intrinsecamente più resiliente e flessibile, permettendo di gestire l’imprevedibilità del mondo digitale senza interruzioni di servizio.

RTO e RPO: quali garanzie di ripristino devi pretendere dal tuo provider di servizi finanziari?

Quando si valuta l’affidabilità di un servizio finanziario, due acronimi sono più importanti di qualsiasi promessa di marketing: RTO e RPO. Essi definiscono la capacità di un sistema di riprendersi da un disastro (un guasto hardware, un attacco informatico, un errore umano) e rappresentano una garanzia contrattuale. Ignorarli significa navigare a vista.

• RTO (Recovery Time Objective): È il tempo massimo che il provider si impegna a impiegare per ripristinare il servizio dopo un’interruzione. Un RTO di 2 ore significa che la tua app bancaria non sarà offline per più di 120 minuti.
• RPO (Recovery Point Objective): Indica la quantità massima di dati che possono essere persi. Un RPO di 15 minuti garantisce che, nel peggiore dei casi, andranno perse solo le transazioni avvenute nell’ultimo quarto d’ora prima del crash.

Queste metriche non sono astratte, ma hanno un impatto diretto sul business. Un RTO lungo può significare ore di vendite perse, mentre un RPO elevato può causare la perdita di transazioni critiche. Le architetture moderne, basate su repliche sincrone e asincrone dei dati in più data center, permettono di raggiungere RTO e RPO vicini allo zero.

La visualizzazione del processo di ripristino mostra chiaramente la differenza tra un’infrastruttura legacy, dove il recupero è un processo manuale e sequenziale, e un’architettura cloud-native, dove il failover su un sistema di backup è quasi istantaneo e spesso automatizzato. La normativa europea DORA (Digital Operational Resilience Act) sta spingendo tutte le istituzioni finanziarie a conformarsi a standard molto rigorosi su questi parametri.

Il seguente quadro mostra come RTO e RPO varino tipicamente nel panorama bancario italiano, un dato essenziale per capire il livello di servizio che ci si può attendere.

Un utente business deve quindi esigere che questi valori siano chiaramente specificati nel contratto di servizio (SLA – Service Level Agreement). Sono la polizza assicurativa digitale della propria attività.

Cloud ibrido o on-premise: dove sono fisicamente i tuoi soldi digitali?

L’idea che i “soldi digitali” fluttuino in un’eterea nuvola è fuorviante. Ogni singolo dato, ogni transazione, risiede fisicamente su dei server, custoditi in data center. La scelta di dove posizionare questi data center è una decisione strategica fondamentale per le banche, che bilancia sicurezza, performance e conformità normativa. Le opzioni principali sono tre: on-premise (server di proprietà nel proprio edificio), cloud pubblico (server affittati da provider come AWS, Google Cloud, Microsoft Azure) e cloud ibrido (un mix dei due).

Le banche tradizionali hanno a lungo privilegiato un approccio on-premise per un presunto maggior controllo. Tuttavia, questo modello comporta costi enormi di manutenzione, difficoltà di scalabilità e un rischio concentrato in un unico luogo fisico. Le neobanche, invece, nascono “cloud-native”, sfruttando la flessibilità e la resilienza geografica dei grandi provider. Oggi, la tendenza dominante, anche per gli istituti storici, è il cloud ibrido. Questo approccio permette di mantenere i dati più sensibili (core banking) su server privati (on-premise o in un cloud privato) e di spostare i servizi rivolti ai clienti (app, sito web) sul cloud pubblico per sfruttarne l’elasticità.

L’uso di data center sul suolo nazionale permette alle banche di rispettare le direttive della Banca d’Italia e del Garante della Privacy sulla sovranità dei dati, riducendo al contempo la latenza per gli utenti finali.

– Deloitte Italia, Digital Banking Maturity Report 2024

Questa scelta è cruciale per la sovranità del dato. Avere i dati dei clienti italiani su server situati a Milano o Roma, invece che a Dublino o Francoforte, non è solo una questione di performance (minore latenza), ma anche di conformità normativa. In caso di dispute legali o indagini, i dati sono soggetti alla giurisdizione italiana. Per questo motivo, i grandi provider cloud stanno investendo massicciamente nell’apertura di “cloud region” in Italia, offrendo alle banche il meglio dei due mondi: la potenza del cloud e il rispetto delle normative locali.

Per un cliente, sapere dove sono “fisicamente” i propri soldi digitali significa avere una maggiore consapevolezza sulla sicurezza e sulla resilienza del servizio che sta utilizzando.

Il rischio del “vendor lock-in” tecnologico che potrebbe paralizzare i servizi bancari europei

La migrazione verso il cloud offre enormi vantaggi in termini di scalabilità e innovazione, ma introduce un nuovo rischio strategico: il vendor lock-in. Questo termine descrive la situazione in cui un’azienda diventa così dipendente da un singolo fornitore di tecnologia (ad esempio, un unico provider cloud) da non poter migrare a un’alternativa senza costi e tempi proibitivi. Per una banca, questo significa mettere il proprio destino e quello dei propri clienti nelle mani di un’unica azienda tecnologica. Se quel provider subisce un’interruzione su larga scala o decide di cambiare drasticamente le proprie condizioni commerciali, la banca si trova in trappola.

Uno studio recente ha evidenziato come il settore bancario si affidi a un numero crescente di sistemi esterni, con una media di 73 gateway di dati per banca, in crescita del 13%. Questa complessità, se non gestita, aumenta l’esposizione al rischio di dipendenza da un singolo anello debole della catena. La soluzione a questo problema è una strategia multi-cloud e multi-vendor.

Adottare un approccio multi-cloud non è semplice: richiede un’orchestrazione complessa e competenze ingegneristiche avanzate. Tuttavia, è l’unica vera assicurazione contro il rischio sistemico derivante dalla concentrazione del mercato cloud nelle mani di pochi, grandi player. Per le autorità di regolamentazione europee e per le stesse banche, diversificare i fornitori tecnologici è diventata una priorità per garantire la stabilità a lungo termine dell’intero ecosistema finanziario.

La vera resilienza, quindi, non sta solo nell’avere un backup, ma nell’avere alternative strategiche che garantiscano libertà di scelta e indipendenza operativa.

Quando le banche potenziano i server per gestire l’ondata di pagamenti delle tredicesime?

Il periodo delle tredicesime, in Italia, rappresenta uno degli stress test annuali più severi per le infrastrutture bancarie. A differenza del Black Friday, che è un picco di spesa, quello delle tredicesime è una “doppia ondata”: prima un massiccio flusso di accrediti in entrata, poi un’ondata quasi immediata di pagamenti in uscita per gli acquisti natalizi. Gestire questo scenario richiede una preparazione meticolosa, che varia enormemente tra banche tradizionali e digitali.

Per le banche con infrastrutture legacy, la preparazione inizia a novembre con il “capacity planning”. Gli ingegneri analizzano i dati degli anni precedenti e pianificano un potenziamento manuale dei server. Spesso, a inizio dicembre, viene dichiarato un “code freeze”, ovvero un blocco di qualsiasi aggiornamento software per evitare di introdurre instabilità nel sistema in un momento così critico. Come confermano i calendari ufficiali, in Italia tra il 15 e il 20 dicembre si concentra il picco annuale, con una data chiave come il 14 dicembre per i dipendenti statali, creando un’enorme pressione concentrata.

Le banche cloud-native affrontano il picco in modo diverso. L’infrastruttura è progettata per essere elastica, quindi il potenziamento è in gran parte automatico. Tuttavia, la preparazione non è meno intensa e si concentra su altre attività.

Durante le settimane delle tredicesime lavoriamo in modalità ‘war gaming’ con simulazioni di carico a novembre e code freeze a inizio dicembre. Il monitoraggio è 24/7 con sistemi di allerta che prevengono problemi prima che l’utente se ne accorga. La doppia onda di traffico – prima gli accrediti, poi gli acquisti immediati – mette sotto stress parti diverse dell’infrastruttura.

– Esperienza di un SRE (Site Reliability Engineer) bancario

Questa testimonianza evidenzia come il focus si sposti dalla gestione hardware (potenziare i server) alla gestione software e predittiva (simulazioni, monitoraggio proattivo). L’obiettivo non è solo “reggere” il carico, ma farlo in modo invisibile per l’utente, garantendo che l’accredito della tredicesima e il successivo pagamento del regalo di Natale avvengano senza il minimo intoppo.

La differenza tra un’esperienza utente fluida e un disservizio durante le feste risiede, ancora una volta, nell’ingegneria che opera dietro le quinte.

L’errore di non avere un piano B per i pagamenti che ti costa il 20% del fatturato giornaliero

Affidarsi a un unico gateway di pagamento, per un’attività di e-commerce o un negozio fisico, è come costruire un’autostrada con una sola corsia e nessun’uscita di emergenza. Al primo incidente, tutto si blocca. Durante eventi ad alto traffico come i saldi o il Black Friday, la probabilità di micro-interruzioni o rallentamenti su un circuito di pagamento aumenta. La conseguenza diretta non è solo la perdita della singola transazione, ma la frustrazione del cliente che, con alta probabilità, non tornerà. Le stime indicano che un’interruzione dei sistemi di pagamento durante un giorno di picco può costare fino al 20% del fatturato giornaliero.

La soluzione è un piano di continuità operativa per i pagamenti, basato su due principi: diversificazione e automazione. Non si tratta di avere semplicemente un’alternativa, ma un sistema intelligente che la attivi automaticamente quando serve. Un e-commerce moderno, ad esempio, dovrebbe integrare più gateway di pagamento (es. Axerve, Stripe, Nexi) e configurarli con logiche di “smart routing”: se una transazione fallisce sul canale primario, il sistema la re-instrada automaticamente su un canale secondario, in modo trasparente per l’utente finale.

Per un commerciante, avere a disposizione diverse opzioni è fondamentale. Ogni canale ha caratteristiche diverse in termini di costi, copertura e resilienza.

In un mondo digitale dove l’alternativa è a un solo click di distanza, garantire un’esperienza di pagamento impeccabile non è più un vantaggio competitivo, ma un requisito di sopravvivenza.

Il rischio di affidarsi solo a hard disk esterni che si corrompono dopo 5 anni

L’idea di fare un backup su un hard disk esterno sembra rassicurante, ma dal punto di vista dell’ingegneria della resilienza, è una strategia estremamente fragile e paragonabile a quella delle vecchie architetture bancarie. Un hard disk è un singolo punto di rottura (single point of failure): può essere rubato, danneggiato da una caduta o, più subdolamente, i suoi dati possono corrompersi nel tempo (un fenomeno noto come “bit rot”) senza che l’utente se ne accorga. Questo approccio è l’antitesi della ridondanza.

Un hard disk esterno è come una vecchia banca con un unico data center nel seminterrato. Se si rompe, tutto è perduto. Le neobanche sono come un sistema di cloud storage distribuito geograficamente.

– Roberto Liscia, Netcomm – Consorzio del Commercio Digitale Italiano

Questa analogia è perfetta. Le infrastrutture bancarie moderne non si affidano a un singolo “disco”, ma a sistemi di storage enterprise distribuiti e ridondanti, che seguono principi ben noti nel mondo IT, come la regola del 3-2-1 del backup. Questa regola, applicata al mondo bancario, si traduce in una strategia di resilienza a più livelli:

• 3 copie dei dati: Esiste sempre una copia primaria (operativa) e almeno due copie di backup. Le banche lo implementano tramite una replica sincrona (la transazione è confermata solo dopo essere stata scritta in due luoghi diversi contemporaneamente) e una replica asincrona (i dati vengono copiati su un terzo sito con un leggero ritardo).
• 2 supporti diversi: I dati non sono mai su un solo tipo di tecnologia o fornitore. Una strategia comune è avere una copia su un’infrastruttura cloud e una seconda su un data center on-premise, oppure utilizzare due cloud provider differenti per evitare il vendor lock-in.
• 1 copia off-site: Almeno una delle copie di backup deve trovarsi in un luogo geograficamente distante, per resistere a disastri regionali come terremoti o alluvioni. In Italia, una coppia comune per il disaster recovery è Milano-Torino, a circa 140 km di distanza.

Inoltre, i sistemi di storage professionali eseguono periodicamente un processo automatico di “data scrubbing”, che legge e verifica l’integrità di ogni singolo bit per prevenire la corruzione silenziosa dei dati, un problema invisibile ma devastante per i backup a lungo termine su supporti fisici.

Fidarsi di un unico hard disk per i dati critici, personali o aziendali, è un rischio che nel 2024 nessun sistema professionale può permettersi di correre.

Perché i pagamenti digitali non devono fallire durante i saldi o i concerti affollati?

L’affidabilità di un sistema di pagamento digitale va ben oltre la semplice transazione economica. In un’era in cui l’esperienza digitale è parte integrante della vita quotidiana, un fallimento tecnico durante un momento di alta affluenza non è solo un’occasione di business persa, ma un segnale di fragilità che erode la fiducia nell’intero “Sistema Paese”. L’impatto economico è la prima, ovvia conseguenza. Con un giro d’affari di 3,8 miliardi di euro per il solo Black Friday 2024 in Italia, ogni minuto di downtime si traduce in milioni di euro di mancate vendite.

Tuttavia, il danno più profondo è reputazionale. Il ripetersi di crash durante eventi ad alta domanda, come i “click day” per i bonus governativi o la vendita dei biglietti per il festival di Sanremo, genera una percezione diffusa di inefficienza e inaffidabilità.

La capacità di un sistema di pagamento di funzionare in modo impeccabile, sia online durante un picco di e-commerce, sia offline in una fiera affollata, è diventata una cartina di tornasole della maturità digitale di un paese. Non è più accettabile che l’infrastruttura sia l’anello debole. La resilienza dei pagamenti digitali è una condizione necessaria per la fiducia dei consumatori e per la competitività delle imprese in un’economia sempre più interconnessa.

Per un business che non può permettersi pause, valutare l’infrastruttura tecnologica del proprio partner finanziario non è più un’opzione, ma una necessità strategica. Iniziate oggi stesso a richiedere garanzie chiare sui vostri Service Level Agreement (SLA) per assicurarvi che la vostra operatività sia costruita su fondamenta solide.