La Circolare 263 della Banca d’Italia rappresenta la declinazione applicativa della disciplina di Basilea II. Pur abrogata in buona parte dal framework di Basilea III, ed in particolare dalla relativa Circolare 285, è ancora valida per talune parti, quali la disciplina dei conflitti di interesse verso i soggetti collegati, e addirittura entra in vigore il nel luglio 2014 con riferimento alla nuova disciplina del Sistema dei Controlli Interni, nota tra gli addetti ai lavori come il 15° Aggiornamento. Tra le innovazioni rilevanti il tema dei sistema informativo (capitolo 8), che per la prima volta assurge ad ambito normativo così esplicito nell’ambito della disciplina prudenziale sui rischi. Infatti sino ad ora la componente ICT era relegata come breve appendice per esempio nei requisiti qualitativi per la validazione dei modelli interni. L’obiettivo del capitolo 8 è dare un framework di riferimento per gli assetti organizzativi, la governance e la gestione del rischio ICT. Ma molti punti rimangono di difficile soluzione e implementazione concreta. Diamo qui una sintesi delle innovazioni normative e delle principali problematiche, rinviando ad altro articolo alcuni approfondimenti specialistici.

1. Il 15° Aggiornamento e Sistema Informativo. Elementi fondamentali

Per una generale revisione dell’impianto normativo di Banca d’Italia rispetto a Basilea II/III e sugli ambii di validità della circolare 263 si vedano le rassegne in [1] e [7]. In breve ricordiamo  che il 15° aggiornamento ha introdotto i capitoli 7, 8 e 9, che riguardano espressamente:

• Il      Sistema dei Controlli Interni (Capitolo7).
• Il      Sistema Informativo (Capitolo 8).
• La      Continuità Operativa (Capitolo 9).

Mentre la decorrenza (nominale) del capitolo 7 è fissata a luglio 2014, per la parte sui sistemi informativi viene dato alla banche tempo sino a febbraio 2015 per adeguarsi. Nel concreto, molte banche sono ancora impegnate nella calibrazione concreta del RAF (Risk Appetite Framework) richiesta nel capitolo 7, e le implementazioni afferenti i sistemi informativi, sia policy sia strumenti, sono ancora in fase di studio.

Venendo ora al tema del nostro contributo, la rilevanza del ruolo del Risk Mgt anche nelle attività di ICT è già stabilita nel capitolo 7, precisamente “(il Risk Mgt) definisce metriche comuni di valutazione dei rischi operativi coerenti con il RAF, coordinandosi con la funzione di conformità alle norme, con la funzione ICT e con la funzione di continuità operativa”.

Allo stesso modo è esplicitata la rilevanza degli ambiti ICT anche nei controlli di III livello affidati alla funzione di revisione interna (Audit): “verifica .. l’adeguatezza, l’affidabilità complessiva e la sicurezza del sistema informativo (ICT audit)”.

Passando ora al capitolo 8, esso riguarda come detto il governo end-to-end del sistema informativo, compresa la gestione del rischio. Da notare che sin dalla premesse è richiamata l’intersezione tra gestione del sistema informativo e temi di rischio operativo e di compliance.

E’ inoltre di interesse, sempre nel capitolo 8,  analizzare la definizione data dal regulator sul rischio ICT.

Come si nota, la definizione è molto ampia (e non poteva forse essere diversamente), non fa riferimento a fattispecie e tassonomie chiuse, ma si limita al richiamo sul contenuto tecnologico di tale ambito. Di nuovo, in modo esplicito, viene richiamata l’intersezione con rischi di altra natura, quali quelli operativi, reputazionali, strategici.

Quali sono dunque le aspettative e le richieste assegnate dalla normativa alle funzioni di controllo, Risk Mgt e Compliance? Lo troviamo declinato nella Sez.II par.6 del capitolo. Da notare l’uso forte dell’espressione “… sono chiaramente assegnate ..”.

In breve, alla funzione di Risk Mgt viene chiesta la misurazione complessiva del rischio informatico, il presidio delle ricorse ICT, il raccordo dei dati afferenti le perdite e la misura del rischio operativo sottostante. Alla funzione di Compliance la sorveglianza sulle norme attinenti (basti pensare alla recente e importante normativa sul tracciamento delle operazioni bancarie sui clienti) e sugli assetti organizzativi.

Ulteriori altre incombenze di assurance sono definite per la funzione di Audit.

2. Principali problematiche nell’ICT Risk

La declinazione effettiva dei principi sopra citati e la costruzione di un apparato di controllo/misura stano generando molte difficoltà nelle banche. Nei limiti di spazio dell’articolo, ci soffermiamo sulle questioni principali.

2.1 Perimetro, ambito, boundary risk

In un qualunque processo di controllo del rischio, il primo passo logico è l’identificazione dei rischi, o come si dice spesso nei contesti operativi, la sua perimetrazione.

Non debbono essere infatti dimenticate sorgenti di rischio o possibili eventi di rischio, come pure vanno evitati fenomeni dannosi di double counting rispetto ad altri rischi.

Alcuni punti chiave vanno rammentati:

• Il rischio ICT non determina nuovi requisiti patrimoniali (i cosiddetti building blocks) di I e tantomeno di II Pilastro. Sul I pilastro i rischi che determinano requisiti di fondi propri sono e rimangono il rischio di credito, di controparte, di mercato e operativo.
• Anzi, nelle definizioni dell’impianto normativo riportate nella sezione precedente, è chiaro come il rischio ICT, nella sua natura o nelle su manifestazioni, è una quota rilevante, meglio un vero e proprio fattore di rischio, fortemente correlato a rischi operativi, strategici, reputazionali.

Più nel dettaglio, ricordiamo che nelle tassonomie sui rischi operativi introdotte con la normativa di Basilea II, gli eventi di rischio sono divisi a vari livelli in Event Types. Questo per distinguere in modo intuitivo le diverse casistiche e facilitare una raccolta dei dati delle perdite e stima dei parametri omogenea.

Al primo livello gli event  types  sono sette, di questi la categoria 6 è rappresentata da “Interruzioni dell’operatività e disfunzioni dei sistemi”. Questa categoria è fortemente connessa, se non sovrapposta, con la tematica del rischio informatico. Ma anche gli event types 1 e 2, rispettivamente frodi interne e frodi esterne, possono essere determinate dalla debolezza di sistemi di sicurezza informatica.

Se ad alto livello tutto questo può sembrare chiaro, nella applicazione si riscontrano alcune difficoltà.

Indipendentemente dall’esistenza o meno di un capital requirement, e dalla necessità di un approccio integrato e olistico al risk mgt, le metriche, metodologie, i sistemi di reporting e di remediation debbono avere una ownership sufficientemente chiara e assegnata.

Su questo primo tipo di problema è cruciale il tema dei boundary risk, cioè della assegnazione di un rischio a una macro categoria o meno. Facciamo prima esempi sui rischi classici di I pilastro:

• Esempio 1. Una perdita su crediti successiva al default può essere determinata dal mancato presidio della garanzia, come la scadenza di un bond costituito come pegno e la sua trasformazione in liquidità non vincolata. Evidentemente tale perdita è generata da rischi di tipo operativo (processi organizzativi o informatici), ma potrebbe essere allocata nel rischio di credito come elemento peggiorativo contributore ai modelli di stima della LGD
• Esempio 2. In un portafoglio di derivati OTC,un processo non corretto di cattura dei prezzi di mercato o dei tassi di interesse può causare non solo valutazioni del mark to market imprecise, ma anche errori nei coefficienti di rischio, determinando attività di hedging sbagliate con le relative perdite. Di nuovo, l’evento si manifesta nel P&L dei book della finanza, ma ha radici operative. Anche in questo caso, la scelta più logica è che il Value at Risk calcolato nell’ambito del market risk incorpori queste casistiche.

La disciplina specifica su ICT risk, e la sua evidente forte compenetrazione con il rischio operativo, rende ancora più difficili le tematiche di allocazione del rischio, ruoli e responsabilità sopra esemplificati. Quali sono poi le competenze dominanti nell’ICT risk? Quelle di risk mgt, tipicamente quantitative, o quelle di dominio, in questo caso tecnologiche? Il risk mgt deve assorbire strutture con skills opportuni o definire solo un set di metodi e di reporting, lasciando presidi specializzati in altre funzioni quali la sicurezza informatica, il dipartimento sistemistico o di data quality? Come detto in premessa, lasciamo ad un secondo articolo approfondimenti e proposte in merito. Si veda l’ottima review in [8].

Il secondo  problema pratico è la necessità di un inventario delle tipologie di rischio informatico, in quanto il semplice rimando alle “tecnologie” della circolare 263 non è sufficiente per identificazione e misura.

A tale proposito ricordiamo che nei primi anni di Basilea (I) i rischi operativi erano definiti per differenza rispetto a quelli di credito e mercato, e solo con Basilea II hanno avuto la loro catalogazione mediante event types e business lines.

Anche nel rischio ICT si dovrà probabilmente definire una tassonomia utile ad un approccio sufficientemente comparabile tra le banche. La parte finale del cap.8 fornisce una lista di classi di rischio e di azioni, ma senza una strutturazione finale.

Quali sono dunque le principali filiere in cui gestire e mappare il rischio informatico? Tra le molte, almeno le seguenti:

• La sicurezza logico-fisica, dai processi di autenticazione (identity management) alla protezione da accessi impropri dei server
• La profilazione degli utenti e dell’accesso ai dati
• La qualità della gestione dei dati e del software. In questo ambito concorrono temi molto vasti quali il data quality (metriche, presidi, key risk indicators) e le proprietà di auditability e trackability del software, cioè potere ripercorrere o riprodurre  anche nel passato qualunque processo ICT
• Il change management, cioè la corretta separazione tra funzioni di sviluppo software e messa in produzione, con possibilità di ripristini e versioning degli asset  software
• Incident management (informative agli utenti, escalation al top mgt, ecc.) e piani di remediation

Oggi tutte queste attività sono distribuite sia in senso operativo sia dei presidi di linea in dipartimenti anche molto numerosi, specie nelle grandi banche. Così come nel rischio operativo è ormai comune l’approccio per tassonomie, e nella funzione di Conformità si parla di legal inventory, anche nell’ICT risk è auspicabile in ogni banca la contestualizzazione degli ambiti, preliminare alla ottimizzazione di processi e responsabilità.

2.2 Metriche per ICT Risk

In passato, specie negli anni di passaggio da Basilea I a Basilea II, con la nascita normativa del rischio operativo e la costruzione dell’ICAAP, misure di rischio come il VaR hanno avuto notevole successo in quanto permettono di unificare secondo una unica grandezza, quella monetaria, le perdite  possibili secondo una certa probabilità in un determinato orizzonte.

Infatti, se negli anni ’90 il termine VaR si riferiva tout court al rischio di mercato, sono poi invalsi nell’uso termini come CreditVaR e OpVaR a rappresentare metriche omogenee applicate agli altri rischi di I pilastro.

La comparabilità e “sommabilità” dei rischi diversi è un valore importante, a prescindere dal noto dibattito internazionale su VaR vs. Expected shortfall.

Nell’ambito dei rischi operativi cui appartiene ICT risk, le figure di rischio sono determinate a partire da parametri di frequenza di accadimento e severity dell’evento.

Su questo vi sono almeno due aspetti su cui le banche debbono indirizzarsi:

1. Tutti i rischi che possono essere ricompresi nell’ICT risk possono avere quantificazione monetaria? O è meglio limitarsi ad un meno ambizioso ma più concreto piano di identificazione e assessment qualitativo, basato su mappatura, punteggi judgmental, definizione di presidi e rischio residuo?
2. Se anche il primo nodo critico consentisse un approccio quantitativo, va valutato se arrivare sino alla fine del ciclo del processo di risk mgt, con metriche quali VaR o altre, o limitarsi a un set di KRI (key risk indicators), da includere in un sistema di reporting tempestivo per il management. Esempio (ambito sicurezza informatica): numero di accesi per ambito e finestra temporale ai database per modifica dati con strumenti di administrator (query) anziché mediante le applicazioni utente. Questo approccio, più vicino alla filiera ICT di produzione, consentirebbe diversi vantaggi, pur con la fragilità di una difficile o impossibile integrazione con gli altri rischi.

Su tutti questi problemi, come detto torneremo presto.

Riferimenti

[1] C. Brescia Morra e G. Mele (2014),  “Le nuove fonti della vigilanza prudenziale”, https://www.finriskalert.it/?p=1000

[2] Banca d’Italia  (2013), “La nuova Vigilanza Prudenziale per le Banche”, Circ.263 15^ Aggiornamento.

[3] Unione Europea (2013), “CRR – Capital Requirement Regulation”

[4] Banca d’Italia  (2014), Nota di chiarimento del 6 giugno 2014 – Sistema dei controlli interni, sistema

informativo e continuità operativa.

[5] ABI (2014), Estratto dal documento “Riflessioni sul capitolo VII per la Gap Analysis”

[6] Banca d’Italia  (2013), “Disposizioni di vigilanza per le banche”, Circ.285.

[7] M.Bonollo e N.Andreis (2014), “Il sistema dei Controlli Interni nella nuova Circolare 263. Sintesi e Aspetti Critici”. https://www.finriskalert.it/?p=1435

[8] M.I. Fheili (2011), “Information Technlogy at the forefront of Operation Risk: Banks are at a greater Risk”, The Journal of Operational Risk.