Impara · Operazioni
Core banking, cloud, outsourcing e regolamentazione tecnologica
Cosa fanno i sistemi bancari principali, come l'outsourcing e le regole del cloud si applicano alle banche, cosa richiede DORA e come la tecnologia supporta il reporting normativo.
Punti chiave
- 01Il sistema bancario di base è il registro della banca per i clienti, i conti, i saldi e gli interessi.Ogni altro sistema dipende da esso.
- 02Le banche possono esternalizzare, anche nel cloud, ma rimangono pienamente responsabili: non devono diventare gusci vuoti e le funzioni critiche o importanti comportano condizioni aggiuntive.
- 03Nell’UE, dal 17 gennaio 2025 è in vigore la DORA che richiede un quadro di riferimento per il rischio ICT, la segnalazione degli incidenti maggiori, i test di resilienza e un registro di tutti i contratti ICT con terze parti.
- 04Il reporting normativo è un problema tecnologico tanto quanto finanziario: i dati devono fluire dal sistema centrale ai report prudenziali, statistici e AML in modo accurato e puntuale.
Una banca è un insieme di promesse registrate in un registro, e se il registro è errato, non disponibile o compromesso, la banca non può sapere quanto deve, pagare i propri clienti o riferire al proprio supervisore. Per questo motivo, le autorità di regolamentazione ora esaminano l'architettura tecnologica, l'outsourcing e la resilienza informatica con lo stesso rigore dei piani patrimoniali.
Che cosa fa un sistema bancario centrale
Il sistema bancario di base è il registro dei dati, contiene i dati dei clienti e dei conti, registra ogni transazione, calcola gli interessi e le commissioni e produce i saldi su cui si basa tutto il resto.
Le funzioni tipiche includono:
| Funzione | Cosa copre |
|---|---|
| Gestione clienti e account | Registri dei clienti, apertura del conto, condizioni del prodotto, stato del conto |
| Registro e registrazione | Registrazione in tempo reale o batch di addebiti e crediti, feed del libro mastro |
| Depositi | Conti correnti, di risparmio e a termine, interessi maturati e capitalizzazione |
| Prestito | Interfacce di originazione dei prestiti, pianificazioni, rimborsi, arretrati, feed di approvvigionamento |
| Interfacce di pagamento | Connessioni a hub di pagamento, processori di carte e conti corrispondenti |
| Configurazione prodotto | Tariffe, commissioni, limiti e regole senza modifiche di codice |
| Dati e reporting | Estratti per finanza, rischio, reportistica normativa e monitoraggio AML |
Intorno al nucleo si trovano altri sistemi: canali digitali, un hub di pagamento, gestione delle carte, onboarding dei clienti e verifica dell'identità, screening delle sanzioni, monitoraggio delle transazioni, tesoreria, finanza e motore di reportistica normativa.
Scelte di architettura
Le nuove banche di solito scelgono tra tre modelli.
- Software con licenza, ospitato dalla banca o da un provider. La banca controlla la configurazione e i dati, ma si fa carico dell'onere dell'integrazione.
- Software come servizio su una piattaforma cloud. Più veloce da lanciare, ma la banca dipende dalla roadmap e dalla resilienza del fornitore, e l'accordo è in outsourcing.
- Banking come servizio di un altro istituto autorizzato. La via più veloce, ma può sollevare la questione se la nuova banca ha abbastanza sostanza propria.
Le autorità di vigilanza non prescrivono un modello, ma valutano se la banca comprende e controlla quello scelto.
Regole di outsourcing
Per outsourcing si intende l’espletamento da parte di un fornitore di servizi di un processo, servizio o attività che la banca altrimenti eseguirebbe autonomamente. Nell’UE, il 30 settembre 2019 sono entrate in vigore le linee guida sugli accordi di esternalizzazione (EBA Guidelines on outsourcing arrangements) (EBA/GL/2019/02), che hanno sostituito le linee guida precedenti, compresa la raccomandazione separata della EBA sull’outsourcing a fornitori di servizi cloud.
Il principio centrale è che la responsabilità non può essere esternalizzata: l’organo di gestione rimane responsabile per tutte le funzioni esternalizzate. Le istituzioni “dovrebbero mantenere in ogni momento una sostanza sufficiente e non diventare ‘gusci vuoti’ o ‘entità cassetta delle lettere’”.
Funzioni critiche o importanti
Le linee guida applicano requisiti più rigorosi quando la funzione esternalizzata è critica o importante, il che significa che un inadempimento comprometterebbe materialmente la conformità, i risultati finanziari o la continuità.
- Eseguire una valutazione del rischio e la dovuta diligenza sul fornitore prima di stipulare un contratto.
- Includere diritti contrattuali di accesso, informazione e audit per la banca e l'autorità competente.
- Controllo della sub-outsourcing, compresa la notifica e il diritto di opporsi o terminare.
- Stabilisci i requisiti di sicurezza, posizione e riservatezza dei dati.
- Avere documentato e testato le strategie di uscita.
- Informare in anticipo l'autorità competente di esternalizzazioni critiche o importanti previste.
Tutti gli accordi devono essere registrati in un registro di esternalizzazione tenuto dalla banca.
Fuori dall'UE
Regole simili si applicano altrove. Nel Regno Unito PRA Dichiarazione di vigilanza SS2/21 Il nuovo regolamento sulla gestione del rischio di outsourcing e di terzi, pubblicato a marzo 2021 ed in vigore dal 31 marzo 2022, riguarda la materialità, la sicurezza dei dati, il cloud e l’uscita pianificata. PRA Lo descrive come destinato a facilitare “una maggiore resilienza e adozione del cloud e di altre nuove tecnologie”.
A Singapore, le MAS Technology Risk Management Guidelines, pubblicate il 18 gennaio 2021, stabiliscono i principi per la governance del rischio tecnologico, l’IT e la resilienza informatica e sono integrate da un avviso vincolante e da istruzioni per la segnalazione degli incidenti.
DORA: resilienza operativa digitale nell’UE
Il Legge sulla resilienza operativa digitale, il regolamento (UE) 2022/2554, si applica dal 17 gennaio 2025 e riunisce in un unico regolamento la gestione del rischio ICT, la segnalazione degli incidenti, i test e il rischio di terzi per la maggior parte delle entità finanziarie dell'UE, comprese le banche.
| Area DORA | Requisito di base per le banche |
|---|---|
| Gestione del rischio ICT | Un quadro documentato approvato e supervisionato dall'organo di gestione, che copre l'identificazione, la protezione, il rilevamento, la risposta e il ripristino |
| Segnalazione incidente | Gli incidenti rilevanti legati alle TIC devono essere segnalati all'autorità competente ai sensi del Articolo 19, utilizzando la classificazione armonizzata e i modelli |
| Test di resilienza | Un programma di test per tutte le entità; per le entità identificate dalle autorità, test avanzati di penetrazione basati sulle minacce almeno ogni tre anni su sistemi di produzione in tempo reale sottoposti a Articolo 26 |
| Rischio di terzi ICT | Una strategia sul rischio ICT di terzi, minimi contrattuali e un registro delle informazioni su tutti i contratti di servizi TIC ai sensi Articolo 28 |
| Supervisione dei fornitori critici | Le autorità europee di vigilanza designano i fornitori terzi di servizi TIC critici e li sorvegliano direttamente ai sensi dell'articolo 31 |
L’articolo 28 stabilisce che le entità finanziarie che utilizzano servizi ICT “devono, in ogni momento, rimanere pienamente responsabili della conformità e dell’adempimento di tutti gli obblighi” ai sensi DORA Il registro deve distinguere i servizi a supporto delle funzioni critiche o importanti. Le entità devono riferire annualmente sui nuovi accordi e informare tempestivamente l'autorità in merito ai contratti previsti per le funzioni critiche o importanti.
DORA Si applica a fianco del EBA In pratica, le banche mantengono un inventario che soddisfa entrambi i requisiti.
Sicurezza informatica
Le autorità di vigilanza si aspettano che una banca conosca i propri asset informativi, li protegga in proporzione alla loro criticità, individui rapidamente gli attacchi e ripristini i servizi critici entro tolleranze definite.
I controlli chiave di solito includono:
- Gestione avanzata delle identità e degli accessi, con autenticazione a più fattori e controlli di accesso privilegiati.
- Sviluppo software sicuro e gestione delle modifiche, anche per le versioni dei fornitori.
- Crittografia dei dati in transito e a riposo, e gestione delle chiavi che la banca controlla.
- Monitoraggio continuo e capacità di operazioni di sicurezza, in-house o esternalizzate.
- Gestione delle vulnerabilità e test di penetrazione regolari.
- Backup isolati dall'ambiente di produzione e testati per il ripristino.
- Piani di risposta agli incidenti che coprono la notifica normativa e la comunicazione con i clienti.
La verifica del beneficiario, l'analisi comportamentale e la forte autenticazione dei clienti proteggono i clienti poiché i pagamenti diventano istantanei e irrevocabili.
Reporting normativo
Le banche trasmettono grandi volumi di dati alle autorità di vigilanza e alle banche centrali. Articolo 430 del CRR richiede agli istituti di segnalare i requisiti in materia di fondi propri, compreso il coefficiente di leva finanziaria, le grandi esposizioni, i requisiti di liquidità, l’onere patrimoniale e le esposizioni ESG, tra gli altri elementi; alcuni istituti devono inoltre comunicare informazioni finanziarie.
La catena dal sistema centrale al regolatore di solito si svolge in questo modo:
- Dati di origine nel sistema principale e in altri sistemi operativi.
- Un data warehouse o un livello di reporting con riconciliazione al registro generale.
- Un motore di reporting normativo che mappa i dati ai modelli di supervisione e alle regole di convalida.
- Revisione e approvazione da parte di finanza e rischio, con controlli documentati.
- Presentazione tramite il portale o il formato del regolatore.
Le nuove banche spesso sottovalutano il lavoro di mappatura dei dati del prodotto ai modelli di reporting prima del lancio, e questo può portare a errori nella segnalazione.
Cosa cercano le autorità di vigilanza in una domanda di licenza
- Una chiara architettura di destinazione, con ogni sistema, il suo proprietario, il suo fornitore e la sua posizione.
- Una mappa delle funzioni critiche o importanti, mostrando quali funzioni sono esternalizzate e a chi.
- Piani di uscita per ogni fornitore critico, realistico in termini di tempo e costi.
- Ubicazione e accesso ai dati, anche per l’autorità di vigilanza e di risoluzione.
- Una resilienza testata, con tempi di recupero che corrispondono alle promesse di servizio del piano aziendale.
- Evidenze di prontezza, come test end-to-end, prove di migrazione e accettazione operativa.
La guida del ECB alla concessione di licenze alle banche fintech chiede ai richiedenti di considerare un piano di uscita per la cessazione delle attività in modo ordinato e solvibile, senza danneggiare i consumatori o richiedere l’intervento della regolamentazione.Le scelte tecnologiche determinano se tale piano è credibile: i dati devono essere recuperabili, i conti trasferibili e i pagamenti in grado di fermarsi in modo pulito.
Il prossimo articolo spiega le linee di pagamento a cui il sistema principale si collega: schemi di carte, SEPA, pagamenti istantanei e regolamento lordo in tempo reale.
Sources(6)
- EBA: Guidelines on outsourcing arrangements (EBA/GL/2019/02) · checked 2026-10-07
- Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA) · checked 2026-10-07
- Bank of England PRA: SS2/21 Outsourcing and third party risk management · checked 2026-10-07
- Monetary Authority of Singapore: Technology Risk Management Guidelines · checked 2026-10-07
- Regulation (EU) No 575/2013 (Capital Requirements Regulation), consolidated text, Article 430 · checked 2026-10-07
- ECB Banking Supervision: Guide to assessments of fintech credit institution licence applications (March 2018) · checked 2026-10-07
Solo informazioni, non consulenza legale, fiscale o sugli investimenti. Avviso normativo.